On-boarding new members to D4H and more…

With today’s training requirements on new firefighter recruits it take a couple of years to develop new/promoted firefighters. We do annual recruiting and annually hold classes for structural firefighting, medical response, hazardous materials and wild-land firefighting. We are about to start on-boarding almost a dozen new recruits…

On-boarding is a process. We have an orientation day where we take a photo of the firefighter (for identification, but also for us to put a face to a name) and we add them to D4H, and provide them a login so they can get acquainted with what is going on. We then have a bunch of other tasks per recruit…

We chose to use Asana for our task management. D4H has task management but we wanted a bit more sophistication in grouping, assignment & deadlines. (We use D4H tasks for equipment/station maintenance tasks.) One thing we do with Asana is group on-boarding tasks for a new recruit, and then clone that whole group of tasks for each recruit.

Our tasks look like this, and we clone them (with assignments / deadlines) one per recruit:

  • [IT] Add to Everbridge (as non-Operational.)
  • [IT] Add to D4H. Check groups, permissions. (Station group, mentee group, Full Fire-fighter or Wildland Team group.)
  • [Admin] Add ID photo to D4H.
  • [Admin] Add to Training Sheet.
  • [IT] Add to Google Groups – including dispatch group.
  • [IT] Add to Wild-land IQS – for qualification tracking
  • [IT] Add to Group Me – for dispatch messaging.
  • [IT] Add to Evite.com (for annual award dinner, family picnics, etc.)
  • [IT] Add to online training system (as needed.)
  • [Admin] Add to FPPA portal (pension)
  • [Admin] Get coded for County Fuel Key (once ready.)
  • [Admin/IT] Get Knox Box code (once ready.)
  • [IT] Add to Everbridge Operational Group (once ready.)

… and this is just the list after we’ve done the initial health / background screening, and paperwork. Actually, there is likely even more.

We found that if we did not explicitly add a task for each step of each new member we’d overlook something for somebody, and it is hard to catch these things after the fact. (New recruits don’t initially notice when they aren’t getting notifications they don’t yet know about.)

One gotcha we have each year with D4H and newcomers …

We are 4 fire stations, one fire community but two main teams (full firefighters FFF and wild-land firefighters WLT) and we are one D4H team. (I’m not sure we’d change to one D4H Organization and two D4H Teams, even if we could. It’d feel wrong to separate things.)

Anyway we do tend to create exercises where we invite FFF and/or WLT as appropriate, and we cannot not use “Full Team” so we use “Selective” attendance for the activity. We lay out our training calendar at the start of the year, which is where the problem arises: Our new recruits get added to D4H and these groups after the exercises are created, so they are not added to the exercise’s attendance … they are not “requested” and they don’t have permissions to add their attendance. It hits us every year.

We have no easy fix for this we just (after on-boarding) create a D4H group of the new recruits and manually updating the exercises they want to go to, requesting the members of that group. New recruits usually have more than enough of their own training, but there are a few (boat training, pack tests, mask fit tests) that they want to attend. It catches us every year.

We are very grateful for the new recruits, however on-boarding is quite a process…

Volunteer Engagement…

As an active Fire Department with up to 300 calls a year and lots of training / qualifications / equipment to manage, we have a lot of reasons for our volunteers to log in to D4H. We’ve found we can get a sense of current engagement (especially with the newcomers) by seeing how long it has been since they last logged in.

https://YOUR-DOMAIN.d4h.org/team/members/lastseen

To get here go to “Planning” / “Members” then “Manage Access” under “Usage & Logs”.

Most newcomers are eager to get involved and check in daily. Some who are busy might go a week between visits. Those who are a month or more away might need a check in themselves. (We’ve implemented a mentorship program where experienced firefighters help new firefighters navigate the – these days – challenging first couple of years of training; structure firefighting / medical response / hazmat / wild-land firefighting. Mentors will check in on new responder to help them remain engaged and make it through those hardest first years. )

Most volunteers experience up and downs in their career, “up years” and “down years”. These show in response numbers, and attendance numbers, but also here.

If volunteer retention is an active issue for your organization (and we are actually very lucky in this regard) then this is a screen you might wish to check on now and then.

Response Utilities Android version 1.0.16

A new release of Response Utilities for D4H on Android is on Google Play. Version 1.0.16.

It contains improvements for Upcoming where attendance is displayed inline with the activity, and can be used to filter from the user’s perspective: all activities, Mine (ones the user is attending or requested to attend), Attending or Requested. Use this to more easily track down the upcoming activity you are looking for.

Upcoming Activities on Android

Improvements in Recent Activities include filtering by activity type: all activities, just incidents, just exercises or just events. Use this to more easily track down the recent activity you are looking for.

Recent Activities on Android

Check out this version of Response Utilities for D4H on Android.

Your D4H Calendar…

Subscribing to your D4H calendar is a must for staying connected to your organization’s upcoming activities. I doubt too many D4H users know they can, and fewer do, hence I’m repeating/reiterating the helpful D4H guide on how to subscribe to your calendar.

Visit your calendar at https://%5BYOUR SERVER].d4h.org/team/calendar/month/ – which you can get to from the Planning menu. Scroll down to the bottom and turn on “iCal” (Internet Calendar) support.

Subscribe-To-D4H-Calendar
Copy your URL (web address)…

Once you have your URL/web address (with the gobbledegook key at the end, which I’ve hidden here … and you should protect yours ) then copy that into a copy-n-paste buffer.

If you don’t know how to “subscribe to a remote calendar” for your calendar client or service, then revisit D4H’s help on “exporting a calendar”, it gives you good examples.

Once you’ve subscribed to the calendar it will fill in the upcoming exercises and events you are attending. (It might take a little time to settle down, after having been added, but once settled it’ll update automatically & regularly.) You can even get automatic calendar reminders / notifications for those activities.

If you are out and about (on the road or otherwise not logged in to D4H on your computer to check) your calendar is what keeps you connected to your organization’s activities. Subscribe to your D4H calendar.

Custom Fields in D4H

D4H supports a large collection of custom fields. We’ve only needed to create a few, but they have proven quite useful.

D4H custom fields

Here are the main ones we use:

Custom Fields on a Member

Custom fields on a member record

We created a “promotion date” (for when promoted from trainee to active firefighter) and then a “general notes” where the member can store their own FD data. (I record my annual pack test times in that field, for me to compete against me.) We have a private “Personnel Notes” field for additional (not public) information. Here are how we configured the private personnel notes…

Custom Fields on an Activity

Custom field on an incident

We added a timestamp for when the patient care report has been filed, and we configure a note (seen by report approvers) to not approve a medical report until the paperwork has been received. Further, we did elect to rename the incident timestamps to match our department’s terminology (to easy member training.)

Custom fields allow us to keep additional data in the right place in D4H.

Roles / Responsibilities

We implement Incident Command System (ICS) on all our incidents; basic on small incidents and we grow it for more complex. We have these main three on all incidents:

  • Command
  • Operations
  • Safety

That said, Firefighter perform various roles on scene – based upon the incident type – and we record many of those roles.

A list of recorded roles.
Just some of the recorded roles…

Within our organization we have personnel at various levels of their career, at various levels of experience, and mentoring the membership through new roles is healthy for the organization. Recording these roles is good for helping “spread the wealth”.

New members need a certain number of successful driving experiences with an officer before they can progress to driving by themselves, or emergent. We record those. Senior firefighters need opportunities to be Command or Operations, and we need to spread that wealth. A healthy organization has experience redundancy, and maintaining that is an ongoing challenge.

We look to “Command” for answers to any question from the incident. We look to “Primary Patient Care” for the patient care report paperwork. We have special roles such as “Call credit during Training/Event” for those unable to respond, but due to Fire Department business. Roles help us add per member detail to a report, and build details of our response.

Keeping track of who performs what roles is valuable data for our membership.

D4H Tags – reportable detail

We use D4H tags to record various aspects of our incidents and exercises. With tags we can do data analysis (should we ever need, including for grant application purposes) which allow us to pull reports that the same detail in the narrative would not.

As a fire department we provide NFIRS (National Fire Incident Reporting System) data on our incidents. We captured many of the NFIRS information requirements into groups of tags.

Our two main groups are “Response Categories” and “Training Categories” and for incidents we tag the main aspect of the call from the former. We then provide additional details through the other “Response *” groups of tags.

D4H-Tags

Our district covers three counties (which provides some interesting challenges) and we chose to record which county the incident occurred within.

We do add some “Special Handling” and “Miscellaneous” tags for other aspects (including events) but those are pretty specific to us/our needs.

Note: D4H doesn’t distinguish tags between incident and exercises, so our “Training Categories” tags (another posting) do show up, and so sometime users incorrectly select them. We created reports looking for any training tags incorrectly added to incidents and that allows us to capture those mistakes.

We’ve found that “D4H tags” are a very powerful and important aspect of D4H.

Designing your incident identifier

Our department gets dispatched via a Computer Aided Dispatch (CAD) system. That system generates unique identifiers and when we are looking up an incident we use that identifier.

D4H allows the user to utilize the system generated identifier, or (although it is hidden behind a ‘magic’ – and confusing to our membership – click on the system identifier text) enter a user entered identifier.

System Generated Identifier
User Entered Identifier

We enter our CAD number as that identifier, but we’ve learned to work around some aspects…

Our CAD numbers start over each year, they are only unique within a year. January 1st the first CAD of a year would be 000001, again.

Also, D4H search is prefix loaded so we:

  • We prefix our CAD # with zeros to 6 digits. This way we can search of CAD #11 without CAD #111 and CAD #1111 getting in the way.
  • We postfix our CAD # with “CAD” and 4 digit year to make it unique.

Here is our design for a unique identifier:

[Zero Padded CAD#]”CAD”[4 Digit Year]

Examples would give:

000001CAD2019, 000002CAD2019, 123456CAD2019

If we ever need to add an “incident credit” or “add on” incident to the CAD we might add a letter, e.g. 000001CAD2019A and so on. If we ever need something added but not through CAD we use the system generated identifier.

This design allows us unique identifiers we can access easily through search.

Inviting Groups in D4H…

We are a mountain fire department with both a community and significant wildland potential (with urban interface.) Our firefighters train for structural firefighting and wildland firefighting (and more.) We also have a wildland team for additional firefighters that respond to wildland fires.

We’ve created four D4H groups:

  • Full Firefighters (FFF)
  • Wildland Team Firefighter (WLT)
  • (Incident-only) Active Full Firefighters (AFFF)
  • (Incident-only) Active Wildland Team Firefighter (AWLT)

For structure fires, medical incidents, hazardous materials, and such only our AFFF respond. For wildland fires, illegal / unattended campfires, smoke reports both AFFF and AWLT respond. We manage their “requested” status in D4H by adding the appropriate group.

Group-Invitations

This keeps our memberships’ percentages correctly representing their standing. They are invited (requested) to the incidents they can attend and not those they cannot, nor those they are temporarily unavailable for.

(More precisely – when creating an incident report – we add the personnel that attended and mark them as attended, then use “Quick Add” to add the correct “Active” response groups. Note that the newly added members are added and left “selected”. We then use “Bulk Action” to “Set Status” to “Absent”. )

Our membership are operational (our responders) or non-operational (administration, support.) When a firefighter has to take an absence we do NOT change their operational status but we temporarily move them out of their “Active” group. (We do have a “Temporary non-Operational” group, but that is less important.)

Working with “Add Another Date” for Event & Exercise Shifts/Slots

We do shifts for staffing community slash days, sign-up slots for annual mask fit testing and arduous pack tests, and more. (We use D4H events for this, rather than try to teach our membership yet another tool.) When creating events (or exercises) in D4H one can create the activity, but “clone it” to multiple dates / times. The title, location, pre-plan and attendance requests are all copied to the multiple activities created.

Note: Once created you can not longer edit them as one, so ensure your activity is correct before you press “finished” and save/copy it.

Once created the event or exercises typically have incrementing sequence numbers, and you can share them (say in an email) with your members by listing the links. We tend to do this in chronological order, allowing them to connect to D4H and sign-up.

Typically we have a limit on the number who can attending. Sometimes it is one member, sometimes it is based upon the number of a resource (e.g. available pack test weight vests.) We list the number that can sign up in the pre-plan, however we do have to manually monitor this since D4H does not support such a limit.

Longstanding bug/workaround…

D4H creates activity records, and multiple “attendance” records for the activity. (One or more per user.) Unfortunately when creating entries across multiple days the activity start & end date/time are correctly calculated, however the attendance start & end date/time are NOT. Somehow (seemingly a code bug) they inherit the *time* of the original activity.

If you create entries for 0900, 1000, 1100 you’ll get activities at those times, but attendance records at 0900, 0900, 0900. This is confusing to membership ‘cos it is presented incorrectly in calendar and the “Are you attending” prompts.

The way we’ve fixed this (since multiple reports over the years to D4H have not gotten this resolved, yet) is to:

  • Use a date range in the events view to gather a list of all these events.
  • Open each event in a separate browser tab (creating a “work list”)
  • Press “Update details” on an event.
  • Go to “Attendance” tab, select all attendees using top/left checkbox, use “Bulk Action” to “Set Period” (set to the correct activity dates) to correct the attendance records, then “Finished” to save.
  • Close the tab once the event view is restored as corrected, taking one off the “work list”.

This bug/workaround does diminish the time saving benefit (for the administrator) of “Add Another Date”, but it still saves creating repetitive activities by hand.