Dispatch

Dispatch is where an alarm gets treated: the operator takes it, reads the instructions, calls the list, and resolves it — every step logged. The Dispatch tab lives in Monitoring (#537) and Data Entry (#559); the queue that feeds it is the Alarm Queue module, and everything it presents — plans, call lists, agencies, texts — was built in the modules that came before. This module runs the loop: get, read, call, resolve — and simulate the alarms you need to create yourself.

How the module progresses

1. Get the alarm and read the screen.
2. Read the four texts — and maintain the temporary one.
3. Work the call list.
4. Resolve calls, then the alarm.
5. Create a signal yourself — Simulate Alarm.
6. Park, time, and map — the moves between call and resolution.

1. Get the alarm and read the screen

Task: take the next alarm and name what each part of the Dispatch screen is telling you.

Get Next Alarm [SHIFT+F10] pulls the highest-ranked alarm you can handle into Dispatch and makes it yours. The screen has three sections: dispatch information on top (the installation, and the indicator row), alarm information (the current alarm — zone, event, priority, times), and the call list below (who to call, in order). Toggle Queue [F9] flips to the Alarm Queue view and back without letting go of the alarm.

Things pop. On receipt, text windows may open by themselves, and a Cameras check mark says the installation has cameras defined. Whatever did not auto-open announces itself with a flashing red label: right-click it and pick the text to read (section 2).

Worked example (Branch TRAIN): with signals on your installation, Get Next Alarm; point at the three sections and say what each shows; toggle to the queue and back.

Guided practice: compare your screen with a neighbour's alarm: same sections, different plan — name what changed and why (different zone, different plan, different list).

Independent practice: an alarm arrives with two flashing labels and nothing auto-opened. Say what that means, what you do first, and why ignoring a flashing label is never an option.

2. Read the four texts — and maintain the temporary one

Task: know which of the four texts you are reading, where each is maintained, and put a temporary text on an installation yourself.

Four indicators, four sources:

A checked indicator means text exists; it opens automatically when your action profile allows it, and flashes red otherwise — right-click the label to open it.

The Texts tab (in #559) is read-and-write: pick a Plan and read its text plus the attached message (edit those in the Action Plans tab, not here); Change Temp Comment edits the installation's one temporary comment — up to 4000 characters, a start and expiry date, and a Display in Dispatch box that makes it pop for operators while in effect. Saving stamps the creating user and date; changing it replaces the previous comment.

Worked example (Branch TRAIN): on your own installation, enter a temporary comment — "keyholder abroad until Friday — call mobile only" — starting now, expiring in two days, Display in Dispatch checked. Then raise a signal on the installation (section 5), get the alarm, and watch it pop.

Guided practice: with the alarm on screen, open all four texts (right-click the flashing ones) and say for each where you would go to change it.

Independent practice: the operator sees a standard fire message on a burglary alarm. Trace the chain that put it there — zone, plan, Msg ID — and name the module that owns the fix.

3. Work the call list

Task: call contacts and agencies in order, validate callers, and leave the trail the log expects.

The list is the plan. The call list shows the plan's agencies and contacts in the sequence you gave them in the Action Plans module. Gray lines are not callable now: a sequence number of 0, or the alarm falls inside the contact's do-not-call window. Codewords and passcards sit with the contact — a caller claiming to be the customer proves it with them.

Call Next Contact [F8] dials down the list: after the call, the event extension box opens — pick the extension describing the outcome (extensions live in Monitoring Event Extensions, #1751) and add a comment. Save, and the called line turns blue with a log entry written; Esc abandons the call unrecorded — no colour, no log.

Zoom before you dial when it matters: a contact zoom shows their full details; an agency zoom shows the register's comment lines, and agencies with special info show it after dialling, before the call resolution opens (the Agencies module). Clicking a phone number dials through whatever dialling integration the site runs — a pager-type number opens the paging dialog instead.

Worked example (Branch TRAIN): on a live alarm on your installation, call the list in order: agency first if the plan says so, then your contacts — extension and comment on each, watching each line turn blue.

Guided practice: one line in your list is gray. Diagnose it from the Action Plans module's two causes, check which applies, and say when the line will become callable again.

Independent practice: a caller says "cancel the alarm, it's me" — walk the validation: what you ask for, where you compare it, and what you do when the codeword fails.

4. Resolve calls, then the alarm

Task: close each call with a resolution, then close the alarm — through the confirmation keystroke — with the extension and comment that tell the story.

Call Res [F4] attaches a standard resolution code to a call you placed — the call's outcome, from the site's resolution register.

Alarm Res [F5] ends the incident: pick the alarm resolution from the list, and SBN answers with a confirmation message carrying a random keystroke — press it (or the shown function button) to confirm; the deliberate extra step is what makes an accidental resolution hard. Then the event extension window: extension and comment, both recorded in the Alarm Log with the resolution.

Resolutions and extensions are registers. The codes offered are maintained centrally — resolution codes by the administrators, extensions in #1751. Extensions follow calls, alarm resolutions, and the Alarm Log's supervisor patch alike (the Alarm Log module).

Worked example (Branch TRAIN): resolve your alarm end to end: Call Res on the last call, Alarm Res with the fitting code, the random keystroke, extension, one-line comment — then find the whole story in the Alarm Log.

Guided practice: explain the random keystroke to a new operator in two sentences — what it prevents, and why a fixed key would not.

Independent practice: the resolution list offers nothing that fits ("bear on the porch"). Choose the least-wrong code, and state where the truth goes so the incident still reads honestly — and who maintains the list you would want extended.

5. Create a signal yourself — Simulate Alarm

Task: raise an alarm that behaves exactly like a real signal — and know the one field that changes that.

SIM ALRM [CTRL+S] creates a signal on an installation: CID (pre-filled with the current customer), Zone — blank simulates a service alarm — Area, Code, Type, and User. The Assign box gives the simulated alarm straight to that user, keeping it out of everyone else's queues (assigned, not acknowledged).

Date and time decide what it is. Leave them blank and the signal is processed as if system-generated — it queues, delays, awaits restores and alarms like the real thing (restore delay applies to the standard alarm types). Fill them in and it becomes a manually entered, log-only record — history, not an alarm.

Worked example (Branch TRAIN): simulate a burglary on your own installation's entry zone, date/time blank; watch it queue, get it, treat it end to end — texts, calls, resolution.

Guided practice: simulate the same zone once more with date and time set to an hour ago, then show where it went — and where it did not.

Independent practice: you need to prove to a customer that their entry delay works. Design the simulation — zone, type, fields blank or filled — and say what you expect to observe in the queue and the log, delay included.

6. Park, time, and map — the moves between call and resolution

Task: hold an alarm deliberately, and bring up the premises map when the responder asks where.

Parking sets an alarm aside — ice blue in the queue, purple when a new signal lands on the parked installation (the Alarm Queue module's colours). Timers hold an alarm for a period — dark green while running, dark red when expired, with the timer codes in the queue's Operator Action column; dispatch actions such as guard dispatch can attach them automatically where configured.

The map button opens the configured mapping integration on the installation's address — the "where is it" for authorities on the phone.

Worked example (Branch TRAIN): on a fresh simulated alarm, park it; verify the queue colour; take it back and resolve it.

Guided practice: state the difference between a parked alarm and an acknowledged one — who owns each, what colour each shows, and which one escalates when a new signal arrives.

Independent practice: the fire brigade asks "confirm the address and cross-street while we roll." Walk your exact moves — map, alarm information, call list — without dropping the call.

7. Quick reference

The four texts: Action Plan (plan's own) · Standard (central register via Msg ID) · Non-Standard (plan message, not central) · Temporary (Texts tab, expiring) — auto-open per action profile, otherwise flashing red, right-click to read.

One-liners: gray call-list line = sequence 0 or inside a do-not-call window · Esc on a call = no log entry, no blue line · extensions (#1751) ride on calls, resolutions and patches · Simulate with blank date/time = real processing, with date/time = log-only history · parked ≠ acknowledged — parked is deliberately held, acknowledged is seen-but-open · one temporary comment per installation, replaced on change.