TL;DR: A call tree is part of your continuity plan. It can fail during actual events for simple, common reasons: numbers become invalid unexpectedly, escalation relies on names that have changed, and the roster is stored in a system that is down when you need it. Treat it like the rest of the plan. Ownership is shared: emergency management sets and tests the reachability requirement, HR and department owners keep personnel and role data current, IT runs access, integration, sync and availability, and responders confirm their own details. Put only the minimum personal contact information needed for notification on the operational list, with consent and access controls, and keep next-of-kin records in the HR system. Test it in your drills, and make sure responders have it on their approved managed or BYOD devices for the day the network isn't available.
The tabletop went well. However, the no-notice notification test three weeks later fell apart.
The call tree activated at 6:05 on a Tuesday. By 6:40, you had managed to contact eleven of the sixteen people on the primary list. Two numbers rang through to disconnected lines. A third number was answered by a spouse who cheerfully said his wife had switched carriers back in the spring. And your alternate for the utilities liaison? She had left that role in March, and no one updated the roster.
As a result, the after-action report included that one sentence all emergency managers read twice before signing: contact could not be established with about a third of the primary notification list within the target window.
The plan was solid. What let you down was the outdated contact data underneath it, which had been stale for months while everyone assumed it was current. In a continuity program, that data is crucial.
The call tree belongs to continuity, not the HR binder
FEMA’s Continuity Guidance Circular includes alert and notification in its concept of operations, alongside orders of succession and delegations of authority. NFPA 1660 places communications within the broader emergency, continuity and crisis-management program, supporting the principle that notification capability should be planned, maintained, and exercised.
Both emphasize the same practical point. The roster that drives your notification step supports your essential functions. If it’s outdated, everything that relies on it suffers, no matter how impressive the binder on the shelf looks.
Where call-downs actually break
After enough exercises, the failure points become predictable. You can prepare for them:
● Numbers become invalid. A disconnected line gives no warning until the morning you call it. People change carriers or phones without informing whoever manages the roster.
● Names change with turnover. If the plan lists Denise instead of "the duty officer," every reassignment quietly creates a gap in the chain.
● One unreachable contact can stall an entire branch. If a contact is unreachable with no named backup, it halts everyone downstream.
● The roster is inaccessible during outages. Contact data stored behind a VPN, an SSO portal, or a share on the affected network is unreachable right when you need it.
● Synchronization does not correct inaccurate source data
You set the requirement, IT builds it
Changing the framing is essential. Contact data usually gets filed under IT maintenance and updated when someone happens to remember. That’s how it becomes outdated. In a continuity program, ownership is shared, and each part sits with a different holder. You, in the emergency management role, set the standard and test it: who needs to be reachable, within what timeframe, and through how many independent paths. HR and the departmental owners hold the authoritative personnel and role data, because they are the ones who know when someone changes jobs, numbers, or employers. IT manages access, integrations, synchronization, and availability. And individual responders confirm their own details where that applies. It works when you define the requirement and test it, holding each owner accountable for their part of the process. It becomes outdated when the roster technically exists somewhere but isn’t anyone’s actual responsibility.
Building a notification path that survives a bad morning
Call trees that work well during a real activation typically have a few characteristics:
● Escalation depends on roles, not names, with real backups at least two deep for every critical role.
● The operational roster carries only the minimum personal contact information needed to reach people during a notification, handled with consent, access controls, and retention rules; next-of-kin and other sensitive HR data stays in the authorized HR system.
● Every responder has multiple ways to be contacted, ensuring that a single carrier or system outage doesn’t disrupt communication.
● The important contacts can be reached off-network, on a device the responder already has.
If you have not tested it, you do not have it
A roster is just a guess until a call-down verifies it. Base that verification on your exercise schedule so it doesn't depend on someone's memory. FEMA continuity planning templates have used monthly telephone-roster updates as a model responsibility, reinforcing that contact information should be reviewed more frequently than the full continuity plan.
The after-action report should mark the beginning of the work, not the end. That issue remains open until the updated roster passes a live call-down and the phones actually connect.
On the day itself, it has to be on the phone in their hand
When the network is struggling, or the VPN is down, or a single sign-on is acting up, a roster that only exists in those systems becomes inaccessible. By then, the contact information should already be on the responder’s phone.
This shows why it helps to distribute the approved operational roster to devices in advance. Where Microsoft 365 is part of the contact-management environment, CiraSync can distribute approved operational contacts to assigned users’ native mobile address books. For organizations using Everbridge, CiraSync Hub can connect Everbridge contact records with Microsoft 365, while CiraSync Cloud or CiraSync On-Prem handles mobile distribution. Administrators can filter which records and fields are distributed, helping keep operational contacts available without exposing unrelated HR or next-of-kin information. Everbridge remains responsible for mass-notification delivery; CiraSync extends approved contact data to Microsoft 365 and mobile devices.
Synchronization does not correct inaccurate source data, which is why clearly assigned ownership and regular verification remain essential.
The best after-action reports identify and close deficiencies. Everyone answered, backups stepped in, the notification step completed on time, and the exercise moved forward. That comes from treating the roster as part of the plan, testing it rigorously, and keeping it accessible even when the corporate systems normally used to retrieve that information are unavailable.
Top comments (0)