Skip to main content

Branches

A branch sits one level above suburbs. Where a suburb is a single zone you draw on the map, a branch groups one or more suburbs into one self-contained operation — its own vehicles and crew, answering only its own suburbs. It is the answer to "for an event here, who responds, and how do we reach them?"

A branch splits your operation, not your alarms. Nothing about how an event is handled changes when you introduce branches — the same rules, the same escalation, the same operators. What changes is who is eligible to answer: a vehicle homed in one branch is never sent to another branch's call. That is the whole point of the split, and the only thing it does.

Branch containment is off until you switch it on

The rule above is enforced by a per-control-room setting (Branch hard cap) that ships off. Until it's on, branches still group your suburbs, filter your boards and shape your reports — but nothing stops a unit being dispatched across branches. The banner at the top of the Branches tab always states which way it is set for your control room. See Branch-aware dispatch below.

A branch usually maps to a town — Witbank, George, Middelburg — but the boundary is operational, not geographic: one town can hold two branches if they don't share vehicles, and a branch can span two towns if one crew covers both. What defines a branch is that resources are not shared across it.

This lets a control room that operates in more than one town (or hands some suburbs to a partner) keep each operation separate: a branch can be served by your own reaction units, handed off to another CleverCam control room, sent to an external armed-response company, or kept as a virtual placeholder while you set things up.

The hierarchy:

Branch  (e.g. "Witbank")
└─ Suburb (drawn map zone)
└─ covered by a Unit
├─ Vehicle (+ tracker for live position)
└─ Responders

The catch-all​

Video The Catch-all branch · 0:33

Every VCR has one branch named Catch-all, created automatically. It is not a real branch — it is the fallback that guarantees nothing is ever orphaned. When you create a new suburb it is added here so it always has a home, and existing suburbs and units were attached to it when branches were switched on.

Two things about it work differently from a real branch, because dispatch treats it as a wildcard rather than a boundary:

  • Its name is fixed. A renamed catch-all is indistinguishable from a real branch on the dispatch screens while still behaving as a wildcard, so the name is locked to "Catch-all". Real branches rename freely.
  • It has no Enabled toggle. There must always be a fallback, so it can be neither disabled nor deleted.

Units left on the catch-all respond anywhere, ignoring the branch cap. Move a unit to a named branch to bring it under the cap.

Because it is not a branch, it is not counted as one: a control room with only the catch-all shows Branches (0) on the tab and on the Overview, with the catch-all card still listed below. That is the normal, correct setup for a single operation — the tab says so rather than warning you about a cap you have never configured. Add a branch when a set of vehicles and crew stops being shared with the rest of the business.

Create a branch​

Video Adding a branch · 0:32
  1. Go to Suburbs in the sidebar and open the Branches tab.
  2. Click Add branch. (An empty Branches tab offers the same Add branch button in its empty state.)
  3. Enter a Label (e.g. "Pretoria East") and pick a Colour.
  4. Choose Who responds:
    • Own units — this control room's own reaction units respond.
    • Partner control room — handed off to another CleverCam VCR (enter the partner's VCR ID).
    • Third party — an external armed-response company; record their contact details (company, phone, email, notes).
    • Virtual / grouping — a placeholder with no responders yet.
  5. Under Suburbs in this branch, tick the suburbs that belong to this branch. Suburbs already claimed by another branch are marked (in Middelburg) next to their name.
  6. Click Create Branch.

Each suburb row on the Suburbs tab shows, in its Branch column, a chip for every branch it belongs to, so you can see the grouping at a glance — and that column's heading menu filters the list to one branch, or to the suburbs in no branch. See The Suburbs list.

See what's inside a branch​

Click any branch card on the Branches tab to open its detail. It shows:

  • Suburbs — every suburb in the branch, with its site count. Click one to jump straight to that suburb's detail.
  • Units homed here — the units whose home branch is this one.
  • Sites in this branch — every site that resolves into it, tagged Pinned by hand or By location so you can see how each one got there, and linking through to the site.
  • A live statement of whether branch containment is on for your control room.

The Catch-all works differently here on purpose: because every suburb is attached to it automatically, listing "its" sites would read as a branch that covers everything. It instead lists only the sites that no named branch has claimed — which is exactly the set its wildcard units are the fallback for.

Edit branch at the bottom of the panel opens the branch editor. The card's own Edit button does the same without opening the detail first. Delete branch is in the Danger zone at the bottom of the branch editor.

A suburb should belong to one branch

Nothing stops you ticking a suburb that another branch already claims, and the editor warns when you do — but it means both branches' units may be dispatched there, which is exactly what a branch exists to prevent. Only do it deliberately, for a genuinely shared patch such as an estate covered by both a local company and the estate's own dispatch.

Give a unit a home branch​

A unit's home branch scopes where it belongs.

  1. Go to Response → Units.
  2. Open a unit (or create one).
  3. Set Home branch. New units start on the catch-all, which means they respond anywhere until you move them.

A unit's patrol suburbs (primary/backup) are separate — those rank the unit for work in those suburbs. The home branch is what decides which work it is allowed to be offered at all.

Branch-aware dispatch​

Branches and suburbs drive who can respond to an event and in what order, controlled per control room under Settings → Dispatch (the Dispatch branch & priority card):

  • Branch hard cap — when on, a unit can only be dispatched to a site in its home branch. A site takes the branch of the suburb it sits in (either force-assigned, or by falling inside the suburb boundary). Every suburb belongs to a branch — its named branch, or the Catch-all if it isn't assigned to one. Units on the Catch-all act as a wildcard (they respond anywhere). A site that isn't inside any suburb has no branch, so it's open to all units, nearest-first — missing map coverage never blocks a response.
  • Break-glass override — in a real emergency an operator can still dispatch an out-of-branch unit by entering a short reason, which is logged against the event. It can be turned off to make the cap absolute.
  • Unit priority order — how the in-branch units are ranked: suburb first then distance, distance first with a suburb bonus (default), or distance only.

The cap is off by default and stays inert until you both switch it on and move units off the catch-all onto a named branch. Full detail — including the bulk tool for assigning units to branches — is on the Dispatch branch & priority page.

Staff branches — technicians, sales reps, coordinators​

Branches aren't only for reaction units. Once a control room has named branches, any staff member on the field roster can be allocated to one or more of them — so a company running Witbank and George can keep each town's technicians, sales reps and coordinators working their own patch.

Allocate branches on the person's profile: People → open the person → Field work tab → Branches — tick the branches they cover. Ticks save immediately.

The rule is the same wildcard rule units use: no branches ticked = works everywhere. A small company that never touches this sees no change anywhere. Once people are allocated, the allocation is a soft preference, not a lockout:

  • Service jobs — a job takes its branch from its site (the same suburb-or-boundary resolution dispatch uses). In the job form's technician picker, staff allocated to other branches are tucked behind a "Show N out-of-branch technicians" toggle with an Out of branch badge — one click brings them back, no override reason needed. Technicians already on the job always stay visible.
  • Sales — a lead has no site, so the lead form gets a manual Branch field (only shown when named branches exist). The sales-rep picker then lists reps covering that branch (and reps with no allocation) first; others sink to the bottom marked — other branch.
  • Boards and lists — the Service Ops board and the Leads page get a branch filter. On the Service Ops board, a signed-in user who has their own branch allocation lands on My branches by default — a branch-bound coordinator opens the board and sees their towns' jobs first, with All branches one click away.

Nothing here is enforced server-side: staff branches guide pickers and default filters, while the hard cap above remains a dispatch-only concept.

Handoff to a partner control room or third-party company (the branch handler) is recorded here but not yet automated.