Reference · built on requestOperator by FibricSafety, security & compliance

Evacuation Roster

Builds the on-site roster from badge, visitor, and shift data at an alarm and proposes the muster list with the unaccounted flagged.

About

Evacuation Roster is an operator job for the minutes after an alarm, when someone has to say who is in the building. It reads presence from the access platform: Kisi presences, Brivo access events by site, Avigilon Alta presence bucket reports, and Gallagher cardholder events. It reads who was scheduled on site from Deputy rosters, When I Work shifts, or Connecteam time clocks, and guest visits from Verkada Guest where you run it. The alarm itself arrives as an event from the access or building platform, or as a signed webhook from your fire panel integration.

It proposes the muster list to the wardens, with each person's last badge read, and a flagged list of people badged in and not yet seen at a muster reader or checked off. Wardens approve and update it in the field.

This is a reference listing. It documents what Fibric would read from Evacuation Roster and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Who badged in and not out: Kisi presences, Brivo access events filtered by site and occurred time, and Avigilon Alta presence bucket reports
  • Cardholder events and access zones from Gallagher Command Centre, including reads at readers you designate as muster points
  • Scheduled people: Deputy rosters for the day, When I Work shifts by location, and Connecteam time clock activity
  • Visitors on site today: Verkada Guest visits with their host, or the visitor sign-in sheet you keep
  • The alarm trigger: an access platform alarm event, a fire alarm point from Desigo CC or Honeywell EBI, or a signed webhook from your panel
  • Warden check-offs and acknowledgements as replies in Microsoft Teams or Slack, or SMS replies through Twilio

Proposed actions

  • Target capability: propose the muster list to wardens in Microsoft Teams or Slack, grouped by floor or zone, with each person's last badge read
  • Target capability: propose an SMS through Twilio to each person still unaccounted, asking for their location, and post the replies to the wardens
  • Target capability: propose the flagged list of unaccounted people to the incident lead, updated as muster reads and replies arrive
  • Target capability: propose the roll-call record after the all-clear, with times, for the emergency action plan file

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Muster from Kisi presence and Deputy rosters

    When the alarm fires, Kisi presences and today's Deputy roster become one muster list per floor in Microsoft Teams, and everyone still unaccounted gets a Twilio text asking where they are.

    With Kisi, Deputy, Microsoft Teams, Twilio

  • Use Gallagher muster readers

    Reads at the Gallagher Command Centre readers you mark as muster points check people off as they arrive. The flagged list in Slack shrinks in place as reads come in.

    With Gallagher Command Centre, Slack

  • Include today's guests

    Verkada Guest visits for the day are added to the list with their host, so the host is asked in Teams about a guest who has not been seen.

    With Verkada, Microsoft Teams

  • File the roll call

    After the all-clear, the operator proposes the roll-call record, with each name, last Brivo read, and check-off time, as rows in Google Sheets for the emergency action plan file.

    With Brivo Access, Google Sheets

Requirements

  • One access control connector with in and out reads or presence: Kisi, Brivo, Avigilon Alta, or Gallagher Command Centre
  • One scheduling connector for who was expected: Deputy, When I Work, or Connecteam
  • One messaging connector for wardens: Microsoft Teams or Slack, and Twilio for SMS to people
  • A trigger for the alarm: an access platform alarm event, a building platform fire point, or a webhook from your panel
Authentication
Reads presence, shifts, and visits through the connectors you bind and their service accounts, and sends lists and messages through the messaging connectors' credentials; it holds none of its own.

Limits

  • No visitor management connector is in the catalog. Fibric links yours on request; until then, visitors come from Verkada Guest or a sheet
  • Presence is only as good as exit reads. A site without out-readers or anti-passback shows people who left hours ago as still inside
  • It builds and updates the list. Wardens decide who is accounted for, and people call the fire service
  • It never triggers or silences an alarm, and it never releases or locks a door

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Evacuation Roster ↗

Questions and answers

What do wardens approve, and when?
The muster list before it is sent, then each update. Wardens check people off, correct the list, and approve the SMS to the unaccounted. The roll-call record is approved by the incident lead. Nothing goes out unreviewed.
What is filed after the all-clear?
One receipt per alarm: the trigger, who was on the list and from which source, each check-off with who made it and when, the messages sent, and the final roll call. It stays with the alarm, drill or real.
Can it run for a drill?
Yes. Trigger it from a drill event and it builds the same list, sends the same messages if you approve them, and files the same roll call, marked as a drill. Nothing in the access platform is changed.
Ask about Evacuation Roster

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.