Overview 01 How it works 02 Escalation 03 Platforms 04 Channels 05 Security 06 ← Back to xplug.in Request a pilot
xplug.in /SmartNotifier /How it works
How it works

The lifecycle of an alarm

An alarm crosses four boundaries between firing in your VMS and being answered by a person. Every hop is recorded, and every hop is retried independently.

Inside the VMS

The plugin runs in-process. On an alarm it resolves the camera and its zone, captures a JPEG snapshot with a five-second timeout, maps the VMS priority to a normalised severity, and posts the event to the backend over authenticated HTTP.

Genetec and Milestone use different priority scales, both inverted — a lower number means a more urgent alarm. Each plugin normalises before the event leaves the VMS host, so a rule written against Critical means the same thing on either platform.

SeverityGenetec priorityMilestone priority
Critical1–501–25
High51–10026–75
Medium101–15076–150
Low151+151+

Ingestion

The backend validates the event, checks the site licence, size-checks the snapshot, and persists the alarm with its acknowledgement state before any notification is attempted. The alarm exists in the record before anybody is told about it.

That ordering is deliberate. If every channel fails, or the machine loses power between ingest and dispatch, the alarm is still on the record as unhandled rather than lost.

Routing

Rules are filtered to those enabled and matching on every configured dimension, then ordered by priority. An empty condition means match-all, so an empty rule is a catch-all.

Matched rules expand to recipient groups, then to recipients, then to their active channels, and the targets are deduplicated — so somebody who appears in two groups that both match still gets the alarm once.

Delivery

One send job per target. Each builds the message in the site's local timezone with severity marker, camera, zone, snapshot, clip link and acknowledge action.

HTTP channels retry three times with 1/2/4-second back-off on rate limits and server errors; a malformed recipient fails immediately rather than consuming the retry budget. Every attempt is recorded with its outcome and the provider's message ID, so a delivery that a provider accepted and then dropped is distinguishable from one that never left.

Acknowledgement and escalation

The responder acknowledges from the message itself. If nobody does within the timeout, the ladder advances. Both are covered in detail on the escalation page — it is the part of the product that is hard to build, and the part worth reading.

Routing, acknowledgement, escalation

30-day pilot

Run it on your own system
for 30 days.

We install it, configure your rules with you, and you see exactly what your team sees. No cost during the pilot. If it isn't useful, we uninstall it cleanly.