Action Plans (Alarm Handling)
Settings → Alarm Handling → Action plans is where a control room decides, per alarm type, how a signal is handled: does it go to a live operator, to the management review queue, straight to the customer, or only into the log? One plan per alarm type, layered per kind of site.
This editor is part of the Advanced Alarm Handling module (see Modules & Capabilities). Plans are applied at runtime only while that module is enforcing them — with the module off, the editor still saves, but routing follows the built-in defaults.
A control room switched to Advanced Alarm Handling does not have to configure anything before the module is useful. The runtime resolver carries a built-in code-default plan per alarm type — the same profile-derived defaults the editor shows before you save (life-safety = Critical priority, technical faults = Review queue, Duress = never call keyholders, and so on). Every event on an enforced VCR resolves a complete plan from day one; anything you then save — a per-type plan, a Site-Mode override, or a per-site override — wins field-by-field over the layer beneath it.
Scopes: one plan, four site Modes
Plans are edited per Site Mode, selected at the top of the page:
- Classic — the base plan for every site. Unclassified sites use it directly.
- Residential / Business / Continuous-movement — per-Mode overrides. A Mode without its own override inherits the full Classic plan — including its Handling — exactly as the runtime resolves it. Per-site overrides (on the site itself) sit on top of all of these.
On the Classic scope the toolbar also offers Reset examples: it replaces every Classic plan with the built-in example set, and removes any customised plan that isn't part of it. Because that wipes all Classic customisation in one click, a confirmation prompt is shown first. Mode overrides are not touched.
Handling — the first control on every alarm type
Every alarm type starts with a four-way Handling choice:
| Handling | What actually happens |
|---|---|
| Control room | The live operator kanban — an operator actions the event. The only handling that runs the full operator flow (dispatch, keyholder calls, SLA timers, checklists). |
| Review queue | Diverted to the management review queue for batch triage — never on the live kanban. Power/comms items auto-close when the matching restore signal arrives. |
| Log & notify | Logged, and the site's primary contact is notified automatically through their opted-in channels (app push → WhatsApp → SMS cascade, email in parallel). No operator is involved. The wording is the central, CleverCam-managed copy for that alarm type (see Customer copy is managed centrally); every delivery attempt is logged. The message is an automatic message: while Automatic messaging is off under Settings → Messaging, Log & notify behaves as Log only — no operator and no customer message. |
| Log only | Recorded for the audit trail. Never surfaced to an operator, never notified. |
Signals handled as Review queue, Log & notify, or Log only count toward the Alarm Autopilot card on the Dashboard — the share of signals handled without an operator.
Fault types: a three-way Handling
The nine fault types — AC mains failure, Comms failure, Hub / device offline, Low battery (system / panel), Low battery (wireless sensor), Sensor / device fault, Supervision / RF loss, Camera issue and Panel trouble — use a simpler three-way Handling, because each is a condition with a restore rather than an alarm someone must answer:
| Handling | What actually happens |
|---|---|
| Hold quietly (sleep) | Control room with the hold window: the card sleeps for the minutes you set, its restore closes it on its own, and it only wakes into the verification stack if nothing restores in time. The default for every fault type, at 10 minutes. |
| Straight to verification | Control room with no hold: the card lands on the verification stack at once. Its restore still resolves it — or keeps it open for an operator; the When it restores choice sits under both of these. |
| Log only | Event log only, never an operator card. Tick Also message the customer to make it Log & notify. |
Under all three, Raise a review item when it keeps recurring files one folded item per site in the management review queue once the same fault has recurred N times in a rolling 30 days (default 3; 1 = every occurrence). A Log-only fault still counts — that is how a quiet signal earns a technician's visit without ever bothering an operator. A plan saved before 2 September 2026 with the old Review queue handling on a fault type reads as Log only with the threshold at 1, and is saved that way the next time it is edited.
The safety floor
Two guard rails apply to Handling, enforced both in the editor and again at the routing layer (so even a bad stored plan cannot bypass them):
- Life-safety types (Panic, Duress, Fire, Medical) always reach a human. Log & notify and Log only are blocked for them.
- Intrusion types (Burglary) need CleverCam sign-off — only a super admin can move them off the Control room, and gets an explicit confirmation prompt when doing so.
Test signals are always auto-suppressed and logged; there is nothing to configure on them.
Open / close: normal arm & disarm
The Open / close group holds five alarm types, and they split into two kinds:
| Type | Fires on |
|---|---|
| Opening (disarm) | Every disarm at the site, whatever the hour |
| Closing (arm) | Every arm at the site, whatever the hour |
| Opening outside hours | Nothing — no alarm code currently feeds this type |
| Closing outside hours | Nothing — no alarm code currently feeds this type |
| Fail to arm | The site did not arm when its schedule said it would |
They are offered in the editor, but no alarm code is mapped to either of them, so a plan saved on one can never match a signal. An alarm type is resolved from the signal's CID alone — nothing on this path reads the site's operating hours — so even if a super admin mapped a code to one of them on Alarm types, it would then fire on every such signal, at any hour. For a customer who wants to hear about arms and disarms, use Opening (disarm) and Closing (arm) and raise them per site.
Opening (disarm) and Closing (arm) are what you set for a customer who wants to hear about every arm and disarm — the classic ask being "phone me whenever anyone opens or closes the shop." Set the type's Handling to Control room and leave Call keyholders in order on: every arm (or disarm) then opens an operator card with the site's call list ready, and the operator works down it. Prefer Log & notify instead and the customer simply gets the message with no operator involved.
The two are configured independently, so arm only, disarm only, or both are all expressible — which is usually what a customer actually wants. A customer who must be phoned on every opening and every closing needs both types raised on their site — raising only Opening (disarm) leaves the arms on Log only.
Where the card lands. A raised arm or disarm opens a live card in CleverCommand's Verification column, the same as any other Control-room signal, with the plan's priority and instructions on it. The operator works it and closes it as usual. (Before 17 September 2026 these cards were born already resolved — they appeared straight in the Resolved column with the master event closed the instant it was created, so operators only found them by scrolling Resolved. That was a defect in how the signal was activated, not a setting.)
Roughly 4 000 arm/disarm signals a day arrive across the fleet. Both types therefore default to Log only — they are recorded and nothing else until you deliberately raise them, so switching on Advanced Alarm Handling never floods a kanban.
Raise them per site (the site's Alarm handling tab) for the specific customers who asked. Raising them at Settings level applies to every site on that Site Mode, and the editor warns you when you do. A busy business site arms and disarms several times a day.
What counts as one open/close. The whole-site arm/disarm codes feed these two types, and since 2 September 2026 so do Disarm from away (E442) and Group disarm / Group arm (E456 / R456) — on the panels that send them, those are the disarm and the arm. On a partitioned site a group code counts per group: the state-change check below compares within the same premises group, so one arm on a three-partition site can raise up to three cards if the type is set to Control room. A panel that re-reports the state it is already in is also ignored — only a genuine arm ⇄ disarm change raises anything, so a chatty panel cannot open a second card for the same action. The comparison only looks back seven days, and only within the same premises group: if there has been nothing to compare against for longer than a week, the next arm or disarm is treated as news and raises regardless. If the check cannot run at all, it fails open — the signal raises.
Not the same as open/close receipts. The open/close receipts feature already texts opted-in keyholders on every arm and disarm. These two alarm types are the operator path — an event on the kanban, with instructions, a priority, a call list and checklists. Use receipts when the customer just wants a message; use these when they want a person to act.
The rest of a plan
Below Handling, each alarm type carries a Priority (Critical / High / Standard / Low), free-text Operator instructions, and — for Control-room handling only — the operator-flow options its profile supports (dispatch and keyholder-call behaviour, timing & SLA timers, anti-abuse & auto-resolve rules, checklists). Two options are available under any handling:
- Raise a review item if this recurs — files one folded item in the management review queue for the technical coordinator once the same alarm type recurs at a site N times in a rolling 30 days (default 3), orthogonal to the handling — a Log-only signal still counts. On by default for the power and technical profiles; a one-off never files.
- Customer notification — a read-only preview of the customer-facing message and reply buttons for that alarm type, shown for Control-room handling and for Log & notify (where it is the notification). The wording is managed centrally by CleverCam and cannot be edited per control room or per site (see Customer copy is managed centrally); the one control you keep is a Notify the customer on/off toggle. Hidden for silent types (Duress), where no customer contact is ever made.
Alarm types are listed under profile headings — Life-safety, Intrusion, Tamper / fault, Power / comms, Technical / fault, Environmental, Open / close. These headings are grouping only: there is no profile-wide rule, and every plan is set on its own alarm type. Each profile section shows only the fields that make sense for it — the fault types get the three-way Handling with the hold window, life-safety offers dispatch.
Keyholder calling — on every alarm type
Every alarm type (except Duress and Test) carries a keyholder-calling control, both on the VCR-level plan and on a site's per-site override:
- Dispatch types (life-safety, intrusion) show a select: Call keyholders before dispatch or Don't call keyholders — dispatch immediately.
- Everything else (tamper, open/close, environmental, power/comms, technical) shows a Call keyholders in order checkbox — the operator works down the site call list; no answer rolls to the next contact.
The defaults follow the SOP for each family:
| Alarm family | Default |
|---|---|
| Life-safety, intrusion, tamper, open/close (incl. the plain Opening / Closing types), environmental | Call keyholders |
| Power / comms (AC mains failure, comms failure, hub offline) | Call keyholders — "your system is offline, is your power off?" is the standard check |
| Camera issue (video loss) | Call keyholders — a dark camera is lost coverage, and control rooms contact the customer for it |
| Technical faults (system low battery, sensor low battery, sensor fault, RF loss) | No call — these are ticket-first signals; turn calling on per type if your control room phones for them |
| Duress | Never call — silent alarm; any outbound call could alert a captor. Locked, not configurable. |
| Test | No call (auto-suppressed) |
Turning calling off for a chronic-abuse site is a per-site override on the site's Alarm handling tab — the VCR default stays "call". On the CleverCommand event page, an alarm type with calling switched off shows a note above the Call List (and Duress shows a red do NOT call warning); the call list itself always stays visible for reference.
If no one answers
Whenever calling is on, an If no one answers select underneath it decides what happens once every contact on the call list has been attempted and none answered:
- Leave the event with the operator (default) — the unanswered chain stays on the operator board for a human decision.
- Dispatch the response unit — Saved, not live yet: the value stores and shows in the plan, and automatic dispatch arms with the Dispatch Copilot; until then the operator still makes the dispatch call.
- Close the event — the event auto-closes with a reversible resolve (never a hard close; reopen it from the Resolved column). Runs on enforced VCRs. Not offered on life-safety types — an unanswered chain on Panic, Fire or Medical must escalate, and the runtime enforces the same floor even if a stored plan were to set it.
Customer copy is managed centrally
The customer-facing message wording and reply buttons for each alarm type are managed centrally by CleverCam. They are the same for every control room and every site, and they are shown read-only in the editor — you cannot change the text per VCR or per site.
Why: when a customer is notified over WhatsApp, the message is sent as a Meta-approved template. Meta must pre-approve the exact wording and buttons before they can be used, so freeform per-control-room copy would break template compliance and the message would fail to send. Keeping the copy central guarantees every outbound message uses approved text.
What you can still control, per alarm type, is whether the customer is notified at all: each type has a Notify the customer on/off toggle in the Customer notification panel. Turn it off and that alarm type is handled without messaging the customer. This is a VCR-level setting — per-site plans cannot override it, and neither the VCR editor nor a per-site editor can change the wording.
The placeholders in the copy — {VCR}, {site}, {time}, and {trigger} (what set the alarm off, e.g. "a person was detected" or "Front Door was triggered") — are filled in automatically when the message is sent. To change the approved wording for an alarm type, contact CleverCam.
Anti-abuse & auto-resolve
Under a Control-room-handled alarm type, expand Anti-abuse & auto-resolve to set noise-suppression rules that close a signal automatically when it matches a known false-alarm fingerprint. Each rule is available only on the alarm types where it makes sense:
| Rule | Available on | What it does |
|---|---|---|
| Wait for restore — hold the event quietly | Power / comms and every technical fault type: AC mains, comms failure, hub / device offline, low battery (system / panel), low battery (wireless sensor), sensor / device fault, supervision / RF loss, camera issue, panel trouble | The hold window. The signal sleeps for the minutes you set instead of hitting the verification stack. If its restore lands inside the window the card closes on its own; if nothing restores, the card wakes into the verification stack when the window ends. Off = no hold, straight to the stack. Default 10 min, 1 min – 24 h. The When it restores choice under it decides what a restore does to a card that has already reached the stack: Auto-resolve (the restore marks it all-in-order and the power-restore auto-complete completes it after its think-time) or Keep open for an operator (the restore only marks it all-in-order — an operator closes it). On the nine fault types this control sits under the three-way Handling itself. |
| Resolve when keyholder chain unanswered | Any non-life-safety type (set via the If no one answers select in the keyholder-calling block, not in this section) | Every contact on the call list attempted, none answered → auto-close instead of leaving it open. |
| Resolve just after a power failure | Burglary, Panic | Suppresses the power-glitch alarm noise that fires within the window you set of a mains-failure signal on the same site. The window is entered as hours / minutes / seconds (stored as seconds). |
| Resolve just after a power restore | Burglary, Panic | Suppresses the restore-surge noise that fires within the window you set of a mains-restore signal. The window is entered as hours / minutes / seconds (stored as seconds). |
| Resolve walk-away trips after closing | Burglary, Open / close (opening/closing outside hours, fail to arm — not the plain Opening/Closing types, which are the arm/disarm itself) | Keeps suppressing the trips a departing keyholder sets off after arming, until the site has been quiet for the cooldown you set. |
| Log a service-ops note when an auto-rule fires | All of the above | Drops a service-ops record each time a rule auto-closes an event, so noisy sites leave a paper trail for trend tracking. |
These rules are set per alarm type, per Site Mode on Settings → Alarm Handling, and can be overridden per site on the site's Alarm handling tab (only the fields you change there are stored — the rest keep tracking the VCR / Site-Mode default).
On VCRs switched to enforced handling, four of the rules above run at runtime and reversibly auto-resolve a matching event — it moves to Resolved (soft-resolve) but an operator can reopen it, and it is never hard-closed: Resolve just after a power failure, Resolve just after a power restore, Resolve walk-away trips after closing, and Resolve when keyholder chain unanswered. They are inert until you switch a rule on for an alarm type, fail open to leaving the event with the operator, and — when Log a service-ops note is on — drop a reversible review-queue note for trend tracking.
Resolve when keyholder chain unanswered is different from the other three: it does not fire from the alarm signal but from the keyholder-call flow in CleverCommand. When an operator works the Call customer flow (or the kanban's inline call picker), attempts every keyholder on the list, and none answer, the call surface records a chain-exhausted outcome. On an enforced VCR where the alarm type's If no one answers setting is Close the event, that outcome reversibly stands the event down — for any alarm type except the life-safety family (Panic, Duress, Fire, Medical), which always escalates. The operator still gets a prominent Roll the best unit — dispatch button on the exhausted call screen, so they can override and dispatch anyway — the rule only decides the default when no one acts.
Life-safety floor: a camera-verified or duress event is never auto-resolved, even where a rule is configured for that alarm type — only unverified noise is suppressed. Resolve when keyholder chain unanswered additionally excludes the whole life-safety family — an unanswered chain on a panic, duress, fire, or medical signal must escalate, never stand down, so those alarm types ignore the rule even if a plan sets it (the editor doesn't offer Close the event on them either).
Wait for restore is the one rule that is not a false-alarm fingerprint: it is the hold window every technical signal sleeps through before an operator sees it. Until 2 September 2026 the runtime used a fixed 10 minutes for the paired fault codes and an hour for the rest; the plan's value now governs both, per alarm type, per Site Mode, overridable per site. A per-site CID monitoring policy with an explicit pair mode (Immediate, or Grace with its own seconds) is more specific and still wins for that one code. A repeat of the same fault, a related technical signal such as a low battery during a mains failure, or a panel housekeeping signal such as a self-test, power-up, firmware update or clock reset, stacks under the held card and does not cut the window short — only a real alarm, its restore, an operator action, or the end of the window changes the card's state. On a non-enforced VCR the legacy 10-minute hold applies.
Checklists and auto-complete on enforced VCRs
More of a plan's fields are enforced at runtime on VCRs switched to enforced handling (today PHQ and a small pilot set of control rooms). All are fail-open — any resolution error falls back to the legacy behaviour — and none change anything on a non-enforced VCR.
- Operator & responder checklists. When a plan defines checklist items for an alarm type, they attach to each matching event as the operator/responder checklist and replace the Operator Checklists templates for that VCR. Operators tick the control-room rows on the CleverCommand kanban and responders complete their rows on CleverResponder, exactly as template-authored rows do — same required-for-resolve gate, same tick / acknowledge / free-text / choice / photo / QR behaviour. An alarm type whose plan defines no checklist items falls through to the legacy templates, so nothing is lost by leaving a plan's checklist empty. Required responder rows attach immediately but only start blocking once a unit is marked on scene — an alarm nobody was sent to never traps the operator behind them (details).
- Auto-complete think-time. Each alarm type's Auto-complete settings — Operator resolves and Power / comms restore, each Inherit / Custom / Off — drive the Auto-complete behaviour for that alarm type: Inherit keeps the VCR/site Settings value, Custom uses the plan's seconds, and Off disables that auto-complete for the alarm type. This lets, for example, a panic resolve linger while a low-battery fault closes quickly. Clava Mode is still the master switch, and the same 3–120 s (operator) / 5–600 s (power) bounds apply to plan values. The Auto-complete section of the editor is temporarily hidden while the manual operator flow is built and tested — the runtime behaviour above is wired and stored values are untouched, but the controls are not reachable in the interface right now.
- SLA response & reminder timers. When an alarm type's Response target or Reminder nudge timer is set to a Custom value (rather than Inherit), the server-side SLA escalation uses the plan's seconds for that alarm type on enforced VCRs — so the reminder/auto-dispatch-pre-select nudges fire on the plan's clock instead of the Response SLAs default — and the operator's overdue badge in CleverCommand uses the same plan timers, so the colour never drifts from the escalation. Inherit keeps the Response-SLAs value. The Customer-cancel timer is deliberately not enforced (it belongs with customer notification, which stays manual).
- Operator instructions & keyholder-call behaviour. On the CleverCommand event page, the plan's Operator instructions for the event's alarm type render as an Action plan note above the event notes (distinct from the site's response instructions), and when the plan says not to call keyholders for that type — Duress always, or any type where the call is switched off — the Call List shows a warning telling the operator to skip the chain (for Duress: silent duress — a call could alert a captor; dispatch immediately).
- Anti-abuse auto-resolve — see Auto-resolve, enforced reversibly above.
Saved-only fields
Two plan fields are not read at runtime yet (each value still saves and round-trips, and applies the moment the field is wired). Both are marked with a Saved — not live yet badge in the editor:
- Skip the keyholder call after business hours (Business scope; Panic and Burglary) — the live after-hours dispatch-first behaviour still comes from the site's classification SLA rule (see Site classification), not from this plan field.
- Customer cancel window — deliberately not enforced: customer self-cancel goes live together with customer notification, which stays manual for now.
Where signals land
- Review-queue items appear in the Management review queue with the alarm type, plan source, and a suggested action; restores auto-close their matching fault items.
- Group power failures are collapsed: when 5 or more sites in the same Area report the same power-family signal (AC mains, comms failure, hub offline) within 30 minutes — typically load-shedding or a substation/network outage — the review queue shows one "Area power failure (grouped)" card for the whole area instead of a card per site. New occurrences keep attaching to it (with a running count), and it closes itself 60 minutes after the area goes quiet. Sites must be assigned to Areas for this grouping to apply. (This is separate from storm handling — weather-driven alarm flooding — which raises its own supervisor alert in CleverCommand.)
- Log & notify stays per-site, but the message is outage-aware: each customer only hears about their own site, and the copy picks the right variant from the type's centrally-managed copy — the Area message ("several sites in your area are also down — likely load-shedding") when 3+ sites in the Area share the failure, or the Isolated message ("no other sites nearby affected — local fault or tampering") when theirs is the only one. Both variants are managed centrally by CleverCam (see Customer copy is managed centrally) and shown read-only.
- Log & notify deliveries are recorded per attempt (channel, status, skip reason) in the notification delivery log; if the site has no contact on file, the signal degrades to log-only and is marked accordingly.
- Automatic messaging off means Log & notify goes quiet. Switching off Automatic messaging — the switch for taking on an imported customer base — holds every Log & notify message, so those signals are only logged: nobody at the control room sees them and the customer is not told. Each held attempt shows in the Outbox as Automatic messaging off, and it is not sent later when the switch goes back on. If an alarm type must still reach someone during an import, give it a handling that puts it in front of an operator until Automatic messaging is back on.
- Every routing decision the module makes is stamped for audit and feeds the Dashboard's Alarm Autopilot card.