Trigger from the Agent and on-site controllers

These two routes cover the cases where a phone or a browser is not available: a member of staff at a fixed machine, and a physical button that must work without anyone touching software.

1. 01

   The Agent route — a signed-in person at a known machine

   Staff with dashboard accounts sign in through the Agent's tray icon. Doing so promotes that machine to an active LAN controller, which enables local incident triggering and All Clear from the tray — and, critically, does so without internet.

   This is the coverage that closes the gap in rooms where staff do not carry phones and there is no time to reach a dashboard — teaching spaces, workshops, reception desks, labs.

   The offline capability is the part worth planning around. If your connection to the cloud fails during an incident, a promoted Agent on the local network can still raise and stand down an incident for the devices it can reach. That is a meaningfully different resilience story from a browser or a phone.

   i

   This is optional and per-machine. Decide deliberately which machines should be promotable — a controller in reception is sensible, one in a public computer room may not be.

   

2. 02

   Make sure the Agent knows where it is

   An Agent with no location assignment can still raise an incident, but loses the advantage of the route. Assign every Agent to its site, building, floor and room.

   i

   See Assign an Agent to a site and room for the full procedure.

   

3. 03

   The controller route — machine to machine

   The on-site controller posts an activation to the platform's controller endpoint. It authenticates with the organisation's connector secret in a request header rather than a user session, because there is no user session at a panel.

   Field or control	What it does
   incidentType	Which of the six types the physical event maps to.
   triggeredBy	Name and email of the responsible person or system, optionally a MassComs user id — validated as an active member of the organisation.
   scenarioId	Optional. Attaches an approved response plan to the hardware-raised incident.
   siteId / siteName / controllerId	Where the event came from.
   id	A client-authored identifier that makes retries idempotent — the same id will not create a second incident.
   kioskRollCall	Optional snapshot of who was signed in, so a hardware-raised incident can still arrive with an on-site list.

4. 04

   Design the integration for retries

   Controllers live on networks that drop. Always send the same client-authored id when retrying an activation — this is exactly why the endpoint is idempotent on it.

   !

   An integration that generates a fresh id per attempt will create duplicate incidents during a network blip, splitting the response between two records at the worst possible moment.

5. 05

   Protect the connector secret

   The connector secret is an organisation-wide credential that can raise incidents. It belongs on the controller, held as a secret, and nowhere else.

   !

   Never distribute the connector secret as a per-device credential when deploying Agents at scale. Use a distinct short-lived enrollment token per machine instead — see Deploy Agents at scale with Intune.

6. 06

   Open the network paths the controller needs

   The cloud connection is outbound HTTPS only and usually needs no firewall change. The optional offline LAN controller feature additionally requires inbound TCP 47809 and UDP 47810 on Domain and Private network profiles.

   i

   If your network edge filters by domain, allowlist the dashboard domain plus masscoms.lon1.digitaloceanspaces.com, and api.elevenlabs.io if you use text-to-speech announcements.

7. 07

   Test the physical path end to end

   Press the actual button, on the actual panel, and watch the incident appear. An integration verified only by a simulated API call has not been tested.

   ✓

   Confirm it worked

   The incident appears with the expected type, the correct site and controller, and the triggering identity you configured.