People

People is the single list of every human in your control room. Responders, control room operators, static guards, office staff, technicians and administrators all appear here once, whether or not they can log in to anything.

Find it under More → People.

The tabs

The page has up to six tabs — Overview, People, Compliance, Leave, Academy and Config — and the working groups sit one level down, as sub-tabs of People.

Tab	What's on it
Overview	Count cards per working group, how people sign in, a compliance summary, and anybody on their way in
People	The list itself, sliced by working group
Compliance	What each person must hold to be allowed to work, and whether they hold it — see Compliance
Leave	What each person has accrued, taken and has left — see Leave. Only where the Roster module is on, and only for people who manage the control room
Academy	Who is enrolled in which CleverCam Academy training, how far they are, who is late, and the certificates they hold — and where you enrol people. See Academy. Only where the CleverCam Academy module is on, and only for people with Manage team
Config	The reference data the rest reads — job classes, absence kinds, leave rules, occurrence codes — see Config. Managers only

A red dot on the Compliance tab means somebody has a credential that is expired or inside its warning window.

The working groups

Under People, an All sub-tab is followed by one per working group, each showing its count:

Tab	Who's on it
Control room	Everyone with the Cmd tick — operators who monitor and dispatch
Reaction	Everyone with the Rsp tick — the response officers you dispatch
Technicians	Everyone on the field team as a technician
Sales	Everyone holding the Sales field role
Guards	Everyone classified as a guard on their profile — only where the Roster module is enabled
Other	Everyone the other tabs don't claim — owners, office and admin accounts, and record-only staff such as general workers

The groups are derived, never stored as a type: the Cmd/Rsp ticks, the field-team roles and the profile's guard classification are the grouping, so a tab can never disagree with what somebody can actually open. One person can sit on several tabs at once — a reaction officer who also operates appears on both Control room and Reaction — while Other is the exclusive catch-all for people on none of them.

The Guards tab appears only when CleverCam has enabled the Roster module for your control room. It carries its own sub-filter — All / Permanent / Casual, the two NBCPSS employment kinds — and each guard's row says which they are. Permanent is the standing workforce; casual covers day-hire relief. With the module off, the same people simply stay under Other.

The Overview tab shows:

• A count card per group — click one to open the People tab already cut to that group. The Control room and Reaction cards also show how many of their people are on shift now.
• How people sign in — how many people hold an email login, a login code, or no login at all. Click a number to open the list filtered to it.
• Compliance — expired, expiring soon, in date, and nothing recorded, across every track. Click it to open the Compliance tab.
• On their way in, when any invites are outstanding.

The list itself is on the People tab, not Overview. Each group sub-tab shows the same list cut to its group, with its own tailored guidance when the group is empty. The search, the App, Access and Roster filters, the column filters, Export CSV and Copy codes all work within whichever slice you're on.

Both the tab and the group are kept in the address bar — /people?tab=people&group=reaction lands on the Reaction slice. The older short form, /people?tab=reaction, still works and lands in the same place.

One list, because a login is an attribute — not a category

It's tempting to split people into "staff" and "team", but that splits the same human in two the moment someone is both — a technician who works in the field and signs in to CleverTech, or an operations manager who carries a firearm and administers CleverOps.

CleverOps treats the person as the identity and their logins as an attribute. Somebody may have:

• an email and password — CleverOps, CleverTech, or CleverSales
• a login code (OTP) on a mobile app — CleverCommand for control room operators, CleverResponder for reaction units
• both
• neither — most static guards and office staff never log in to anything, and still need PSIRA and contract tracking

The Access column shows exactly which. Email logins are highlighted; login-code apps are shown in grey.

A login code is not the same as access

Every person record is issued a login code automatically by the system, so having one does not mean the person can sign in anywhere. That's why a guard shows No login even though a code exists on their record.

Granting app access

Access to the two mobile apps is an explicit tick on the person, shown in the Access column as two small toggles:

Toggle	App
Cmd	CleverCommand — for control-room operators
Rsp	CleverResponder — for reaction units

Click a toggle to grant or remove that app. A solid pill means access is on; a dashed outline means it is off. The toggles appear for anyone with a person record if you have permission to manage the team; without it the column stays read-only.

These ticks are now the only thing that decides who opens which app. CleverOps used to carry a separate Type (Reaction unit, Control room, Guard, Office, Technician) alongside them, and the two could disagree. Type has been retired: what somebody "is" was only ever a proxy for which app they open, so the app itself is the answer. Response and Control Room list people by these ticks, and so does this page.

Removing access from someone on shift

Unticking an app for a person who is currently on shift asks for confirmation first, naming them. Removing a responder's app while they are out on the road is not something that should happen from a single stray click.

Unticking is a real revoke

Removing a tick takes the person off those lists immediately — they stop appearing on Response or Control Room, and stop being offered for dispatch — and the logins follow the tick: untick Rsp and their next CleverResponder one-time code is refused (a small set of grandfathered permanent demo/reviewer codes is the only exception); untick Cmd and CleverCommand refuses their login code and PIN at their next sign-in.

Viewing People

1. Open More → People, choose the People tab, and pick a slice — All, or a working group.
2. Search for somebody by typing in the box that leads the filter bar. See Finding one person below.
3. Filter with App — CleverCommand, CleverResponder, CleverTech, CleverSales, CleverOps — with Access — Email login, Login code, No login — or, where the Roster module is on, with Roster — Rosterable, Not rosterable. Each option shows its count, scoped to the slice you're on.
4. Each row is one line. Out of the box it shows:
   • Name — the profile's full name where one is captured, else the seat label (the one name rule every page shares — the roster reads the same), with a muted summary beside it: the seat label where it differs, the email address, their field-app roles (Technician, Sales) when they're on the field roster, the guard kind and Rosterable where the Roster module is on, No operational record for somebody who holds only an account or a roster row, and N seats for this person here when one human holds two seats in this room. Hover for the full text. A part leaves the summary once you switch on its own column (below), so nothing reads twice
   • Access — one chip per app they can sign in to, or No login. Company owners and company admins carry an Owner or Admin pill at the front, because that outranks every app tick beside it
   • Job title — from their profile. Where no job title has been captured it falls back to what the company directory knows — Company owner, Company admin, or their CleverOps roles — so the Other slice says what an account is for
   • Compliance — four dots, one per item on the statutory track (PSIRA, firearm competency, driver's licence, first aid), coloured red for expired, amber for expiring soon, green for in date and grey for nothing recorded, followed by a short summary such as 1 expired, 41 d or All in date. Hover for the full count. The dots are a summary only — the dates and the certificates live on the Compliance tab and on the person's own record
   • Actions — Login info (the person's sign-in detail and codes — see How they sign in below) and a Manage button for people with no profile of their own (see below). Removing somebody happens inside what the row opens, not on the row — only someone who cannot open the person's workspace still gets Remove here

The rest of what the list knows sits in columns that start switched off — see Choosing your columns. Compliance dates and certificates, PSIRA numbers and the person's full record live on the workspace, not on the list; open a row to see them.

Choosing your columns

The list does not show every column at once. Columns ▾, at the right of the filter bar, is where you decide which ones it shows — tick a column to bring it in, untick it to hide it. The button says how many are currently hidden, so a column somebody switched off is never a mystery. Name is listed too, ticked and greyed with always beside it: it cannot go, and the list says so rather than leaving it out.

Put them in the order you read them. The ↑ and ↓ beside each column in Columns ▾ move it one place; a column heading's own menu (the small ▾ that appears when you hover a heading) has Move left and Move right for the same thing. Name stays where the list put it, but other columns may move past it.

Your choice is yours alone and it follows you. Columns, their order and the sort are saved against your login, not the browser, so the list looks the same on the control-room machine and on your laptop, and changing it does not touch what your colleagues see. Reset to default view puts everything back.

The five columns above are what you start with. Every other column starts switched off — the page costs nothing extra to load them, because they ride on the same data the list already fetches:

• Sign-in — how they get in, in a word: Email, Login code, Email + code, or Label only for a seat nobody signs in with (a record kept for PSIRA, the roster and the file — the two doors: a login seat and a label-only row are both people). No login is a roster row with no seat here and no account
• Call sign — the seat label where it differs from the name — the ARU 1 an operator actually knows somebody by
• Groups — the working groups the person sits in, the same slices as the sub-tabs
• Field duties — Technician and/or Sales from their field-roster row; App access only for a roster row with no duties
• Guard — Permanent or Casual, from the profile (Roster module only)
• Rosterable — whether the roster may place them (Roster module only)
• On shift — Since 12 Jul 2026, 14:05 while the seat is on shift; blank otherwise
• Email — the account's address, else the contact address on the profile
• Phone — the profile's number, else the account's
• Employee no. — the clock / employee number on the profile
• Start date — from the profile
• Home suburb — from the profile
• Last sign-in — the newest sign-in to a control-room or field app; Never when there is none on record. CleverOps sign-ins are not counted
• Login code — the durable CleverCommand login code, for seats with the Cmd tick only. PINs are never shown
• Added — when the seat (or, for a roster-only row, the roster row) was made
• Seat ID — the seat's record number in this control room; blank for account-only and roster-only rows

Sorting the list

Click a column heading to sort by it; click it again to reverse. An arrow marks the column the list is sorted on. The heading's ▾ menu offers the two directions by name — A → Z / Z → A for text, Newest first / Oldest first for dates, and plain words where a letter would mean nothing: Logins first / Label-only first on Sign-in, Needs attention first / In date first on Compliance (something expired first, then the soonest expiry), On shift first, Rosterable first.

These headings sort: Name (the default), Sign-in, Job title, Compliance, Call sign, Groups, Field duties, Guard, Rosterable, On shift, Email, Employee no., Start date, Home suburb, Last sign-in, Added and Seat ID. Access, Actions, Phone and Login code are not sortable; their menu says so.

Every person in the control room is loaded up front, so a sort orders the whole list — not just the rows on screen — and rows with nothing in the column sort last whichever way the list runs. Like your columns, the sort is saved against your login.

Filtering from a column

A column's ▾ menu is also where its filter lives, so the answer to "how do I narrow the list by this" is the same for every column. Pick a value and the list is filtered; the heading's ▾ turns solid while a filter is set. The App, Access, Guards and Roster dropdowns in the filter bar are reachable from their columns too — App from Access, Access from Sign-in, the Guards tab's Permanent / Casual from Guard, and Roster from Rosterable.

Three filters exist only in a heading's menu. While one is set, a chip naming it appears in the filter bar — even if you later hide the column — with × to clear it:

• On shift — On shift now or Off shift
• Field duties — Technician, Sales, App access only (a roster row with no duties), or Not on the field roster
• Compliance — Something expired, Expiring soon, All in date, or Nothing recorded

Clear filters appears whenever any filter is set and clears them all, the column ones included. Column filters are session-scoped — they clear when you leave the page.

Exporting the list

Export CSV, beside Copy codes, downloads the people currently listed — the sub-tab you're on, minus whatever the search and filters exclude, in the order on screen — as a spreadsheet with the columns on screen, in your order, Name first. A view built for a PSIRA audit downloads as a PSIRA audit. Dates are written as ISO so they sort and Excel reads them; Actions has nothing to export and is left out. The file is stamped with the slice and the date — people-reaction-2026-09-11.csv.

Finding one person

A busy control room runs to well over a hundred people, and scrolling a list that long to check one person's ticks is not reading — it's hunting. The search box leads the filter bar on the People tab and narrows the list as you type.

It matches everything the row shows:

• the name, and the seat label beside it where the two differ — the call sign an operator actually knows somebody by (ARU 1, Control 2)
• the job title column
• the email address
• the field-app roles — Technician, Sales
• the guard classification (Permanent guard, Casual guard), the Rosterable mark, the Owner and Admin pills, and No operational record

It also matches their phone number, which the row itself doesn't print. That is deliberate: the number that just rang is far more often to hand than the spelling of a surname. Any way of writing it finds them — 082 123 4567, +27 82 123 4567 and 0821234567 are one number, and part of it is enough, so the last four digits off a caller ID will do.

Search narrows the list, not the counts. The tab headings keep showing the true totals — People (143), Guards (61) — and so does each filter's own count, exactly as they already ignore one another. A small N of M beside the box says how many of the tab's people are showing, and Clear empties the box. Copy codes, further along the bar, acts on the rows that are showing, so a search is also how you copy login codes for just part of a team.

The search reads the whole list, not the part of it on screen — this page loads every person in the control room up front, so nothing can hide below the fold.

When nothing matches, the empty state says which thing is hiding them rather than leaving you to guess:

What it says	What to do
N people match in this group, but the filters beside the search are hiding them	Set App, Access or Roster back to their All option
Nobody on this tab. N people match elsewhere in this control room — look on All	The person is in a different working group — switch to the All sub-tab
Nobody in this control room matches	Check the spelling, or try part of an email address or phone number

The box keeps what you typed when you move between the working-group sub-tabs, so you can carry one search across them.

On their way in

People who have been invited but haven't joined yet sit in an On their way in card on the Overview tab. There are two kinds, and the card says which is which:

• Email invite — tied to one person and one address. Each invite is a card showing the address, the person it was raised for, the roles they will join with (named, not slug-coded), who invited them, and when it expires. When they accept, their new account attaches to that person's record, so they stay one row on this list rather than appearing a second time.
• Join code — untied. It shows the six-character code, whether it grants full or limited access on join, Copy code, and Revoke. Anyone you send it to joins as a company admin, so treat it as a credential. Create join code (owners only) mints one for somebody who will sign themselves up.

The card is visible to company owners and company admins.

How far an invite has got

Every email invite carries a four-step line — Sent → Opened → Signed up → Accepted — so you can see where somebody is stuck without asking them:

Step	What lights it	What it tells you
Sent	An email, WhatsApp or SMS actually left	Which channels it went out on. No send recorded means only the link was created (or the invite predates send tracking).
Opened	They opened the invite link	Which message they opened it from — the email, the WhatsApp / SMS message, or a copied link — and when.
Signed up	An account exists on the invited address	Since when. Signed up, but hasn't opened the link and accepted is the classic stall: they registered on their own and never went back to the invite. Send it again.
Accepted	They pressed Accept invite	When. Accepted invites stay on the card for 14 days, then drop off.

Under the steps, a pill per channel gives the detail: Email · sent / link opened, and WhatsApp · sent / delivered / read / not delivered (or SMS · … when WhatsApp couldn't reach them and it went as a text). WhatsApp's read is the messaging network's own read receipt. Email has no read receipt, so its signal is the link being opened — the link in each message is tagged, which is how the card knows which one they used.

What you can do with an open invite

• Resend email / Send on WhatsApp — sends the same link again on either channel. WhatsApp asks for the mobile number (remembered from last time, and editable, so a wrong number is fixed the same way). The message names the email address they must sign up with, and goes as an SMS if WhatsApp can't reach them.
• Change email — for a mistyped address. Enter the right one and Save and email it: the link already sent stops working, the 14 days start again, the invite is emailed to the corrected address, and the card keeps a was old@address note. Their roles and the person the invite is attached to don't change, so there is no need to revoke and start over. It refuses an address that already has a CleverOps account — attach that account from the person's Email account card instead.
• Copy link — to hand over yourself.
• Revoke — cancels it (needs Manage team).

An expired invite stays listed for 14 days with Re-invite by email and Re-invite on WhatsApp: one click gives it another 14 days and sends it. The link is the same one, so the message already sitting in their inbox works again too. Don't re-add the person from Add person — that creates a second seat for the same human.

The person workspace

Clicking a row opens that person's workspace — one screen holding everything about them, in the order you actually ask about it:

Tab	What's on it
Person	Who they are — personal and company details, the guard classification, the job class they are paid as, gender, EE category and languages (the Employment Equity return, and what a cover line may lawfully require), transport mode and home suburb, and an ID number with a SA ID / Passport / Other dropdown in front of it, checked against that document type and against duplicates — both warn, never block
Roles & access	What they may do, per control room — the seat's roles and app access, the per-room company-admin stamp — and, right under those, how that seat signs in: the CleverCommand login code + PIN, the CleverResponder one-time code, and the email account
Field work	Their CleverTech / CleverSales field-team detail
Compliance	PSIRA, competency, licences and any client-track items — each date carrying its own certificate and its sub-category (a grade, a firearm type, a licence code), and the Check with PSIRA register lookup

This is the only place a person is managed. Company Settings used to own half of it and the invite flow owned another slice; both are gone. What is left in Company Settings → Owners is ownership alone, because ownership reaches control rooms that don't exist yet and is appointed a handful of times in a company's life.

Roles & access

A person is one human per company. A seat is that human in one control room. Everything operational hangs off the seat — the sign-in codes, the app ticks, duty state, and the company-admin stamp — so roles and access are set per room.

Where the company has one control room and the person sits in it, the tab opens straight on that seat. Where there are several, the tab first lists every control room the company owns, one line each, showing whether the person has a seat there, whether they're a company admin in it, which apps that seat opens, and whether they're on shift right now — pick a room to edit that seat.

• Add seat on a room where they have none creates a seat with no app access at all — a record-only seat. The roles and app ticks appear the moment it exists.
• Removing somebody from the list removes their seat in this room only. Seats in other rooms, their field-team row and their email account survive.

Making somebody a company admin

Company admin here, above the roles, stamps this person as a company admin in the selected room. Admins manage that room's people — seats, app access and roles — and its settings. They cannot appoint owners or other admins.

The rule, and it is enforced in the database rather than merely hidden in the UI:

• Only a company owner (or a super admin with super-admin mode on) can set it. Everyone else sees the toggle disabled, with the reason.
• The person must already have an email account linked — a company admin signs in to CleverOps.
• You cannot use it on yourself. Nobody changes their own tier.
• A company owner shows it ticked and locked: owners already have everything an admin has, everywhere, and their ownership is managed in Company Settings → Owners.

Because the stamp is per room, somebody can administer one control room and hold an ordinary seat in another.

Roles and app access

Under the room you picked, everything that seat is allowed to do is one thing: roles. Multi-select chips, grouped by what they're for — Apps, Service ops, Back office, Oversight. Tick what a person does; each role brings everything that job needs, apps included, and a role that signs someone into an app names that app right on the chip. There is no per-capability editor: when a role grants too much, the catalog splits it into a finer role instead (Asset manager beside Asset inspector is the pattern).

Role	Grants
Technician · CleverTech	The CleverTech app, and field service execution
Sales · CleverSales	The CleverSales app, and the sales & leads screens
Responder · CleverResponder	The CleverResponder app — reaction crew, no CleverOps permissions
Fleet · CleverResponder	The Fleet surface inside CleverResponder — every vehicle, live positions, trip history, read-only
Cameras · CleverResponder	Operating a vehicle's dashcam from Fleet — live picture, snapshot, keep the last moment. Ticking it ticks Fleet with it. The same permission as an operator's Live view on the Control Room page
Operator · CleverCommand	The CleverCommand operator app, plus working the events queue from CleverOps — resolve events, live view, snooze cameras, AI Caller, site access, manual and bulk events, call lists and notes
Technical coordinator	Service operations and quote approval, plus the Coordination tab in CleverTech
Stock controller	The store — receiving, stock moves and counts — plus the Stock controller surface in CleverTech
Asset manager	The asset register, plus the Assets section in CleverTech
Asset inspector	Asset inspections only — the Assets section in CleverTech, read-and-inspect
Sites admin	Customers, sites and contacts
Billing / accounts	Invoices, payments and billing configuration
Cashier	The front desk — record customer payments, see the ones you took, cash up your own drawer, and run the Till. Billing opens as the Payments tab alone
Fleet manager	Vehicles, firearms, assets and trackers
Manager	What the company pays CleverCam
Control room manager	Operator roster, roles, units, shifts, reports and the review queue
Auditor	Reports and the audit trail, read-only
Administrator	Every capability, including ones added later — except what the company pays CleverCam, which stays with Manager

What does each role grant? at the bottom of the card folds open to the exact list behind every chip — reference, not controls.

The app roles sign in against an operational record rather than a CleverOps account, and ticking one for somebody who has an account but no record on this workspace creates the record then and there. That is the normal state for a company owner: an owner is a company member, never a control-room one, so they had no record for the apps to sign in against — and CleverResponder turned them away with "ask your manager to add you on the People page", which is this page. The person then signs in with their own CleverOps email and password — no code, no second account. Fleet stands on its own: it admits an owner or manager into CleverResponder's Fleet and Drive surfaces without making them crew, and anyone already holding Manage fleet & vehicles has it without the tick. Cameras sits on top of Fleet: seeing a vehicle's dashcam and the footage it has already sent comes with Fleet, but asking the camera for a live picture or a snapshot needs this tick — so ticking Cameras ticks Fleet as well, while unticking Fleet leaves Cameras alone, because it is the very same permission an operator's Live view grants on the Control Room page and removing a responder's fleet must not blind an operator. (What an operator may do inside CleverCommand is still set per operator on the Control Room page — the Operator chip grants the sign-in and the CleverOps half.)

Every tick is live

There is no Save button and no undo. Each tick writes immediately, so a stray click grants or removes real access the moment it lands. The editor says so above the chips.

When something can't be set

The chips always show everything, and say why one is unavailable rather than hiding it:

• No email sign-in — the CleverOps roles have nowhere to live. Invite or attach an email account in the Email account card under the roles first. The app and field roles still work.
• No CleverOps account on this workspace — CleverOps roles need an email invite, sent by a company owner or admin. A mobile-app sign-in is not a CleverOps account: most responders and operators have one, and it grants nothing in CleverOps. The reason line says so rather than claiming they "have an account".
• Company owner — owners always have every capability everywhere and can't be scoped.
• This person is a company admin — only an owner sets what another admin may do; setting an admin's roles reaches across your own tier. Their app access, field roles and seat are still yours to change if you manage this room's people.
• You aren't an owner or admin — a member's CleverOps roles are set by a company owner or a company admin. Everyone else sees the reason; their app access, field roles and seat are still yours to change if you manage this room's people.
• Administrator is the one chip an admin cannot tick — it makes the person a company admin, so it stays with the owner. The chip is locked with that reason.
• No operational record — only blocks the app roles when the person has no account either. Anyone holding a CleverOps account can be granted an app straight from here; the seat is created by the tick.

People with no seat in this room

An Account only person — a company owner or office admin — or a field-team entry belonging to nobody on the list has no seat here to open. Their row carries a Manage button instead, opening Roles & access and Field work on their own, so seating them in a room is one click away rather than a dead end.

How they sign in

Directly under the roles of the room you're editing sits How ‹name› signs in — the sign-in for that seat. A sign-in never decides a role; it only establishes who they are, and one person may hold several at once. The manager who signs into CleverResponder with a one-time code in the vehicle and with their email at the desk is one person, with one set of grants, seeing the same surfaces either way.

The panel shows one card per app the seat's ticks open, and nothing for apps it doesn't — the two mobile apps use different credentials and they are not interchangeable:

Card	Shown when	The credential
CleverCommand	Operator is ticked	A login code and its PIN, handed over together. The login code never changes; the PIN is the 4-digit code that pairs with it. Both keep working until you press New PIN — which generates a fresh one and signs the operator out of any open session.
CleverResponder	Responder is ticked	A single 15-minute one-time code, on its own — no login code, no PIN. Generate 15-minute code (or New code) mints one and copies it, showing the minutes it has left. A handful of demo and app-store-reviewer logins carry a one-time code that never expires, marked as such. CleverResponder stopped accepting the login code + PIN in August 2026 — see the app's sign-in section.
Email account	always	Whether an email account is linked, and — for owners and company admins — the invite / attach controls. See Linking a person to their email account below.

Where the person's CleverOps account is linked to the seat, the app cards say so: they can also sign in to that app with their own email and password.

Somebody with no sign-in at all is told so plainly, and told that it's fine: they can be rostered, allocated, paid and audited without ever opening an app — the floor of the model, and most static guards and relief staff. Tick Operator or Responder in the roles above, or link an email account, to give them a way in.

The same codes are reachable straight from the list, without opening the workspace: each row has a Login info button that opens the same panel on its own, so the two can't drift apart.

Copy codes at the top of the list copies the CleverCommand login codes of the current view — the tab you're on, minus anything the filters exclude — as name, app and code. PINs are never included, and neither are one-time codes: they rotate, so a pasted list of them is wrong by the time it is read. Responders therefore have nothing to copy — mint their one-time code from Login info at the start of a shift.

Field work

The Field work tab is the person's field-team detail — hourly rate, working hours and days, specialisations, regions, commission and time off — plus whether they're on the field team at all. (The word roster belongs to the Roster module: whether the roster may place a person is the Rosterable field on the Person tab.) Their field duties show here for context but are granted under Roles & access; a row with no duties reads app access only — they sign into CleverTech but appear in no technician or sales list.

Somebody can be on the roster without an email account. They can be assigned work, but neither app will sign them in until an account is linked, and the tab says so.

Filtered views elsewhere in CleverOps

Two other pages show slices of this same list, because those places need operational controls rather than HR detail:

• Response → Responders — the Reaction unit people, with their login codes, tags and unit crewing
• Control Room — the Control room people, with their operator credentials

One thing, and one thing only, is not on this page: who owns the company. That lives on Company Settings → Owners, because ownership reaches every control room including ones created later, and appointing an owner should never sit on the same screen as ticking somebody's app access. Everything else that used to be on Company Settings → Team Members — company membership, per-workspace permissions, invites, removal — is here, on the person.

Guards, office staff and technicians appear only on this page; they're never offered when building dispatch units in CleverCommand.

Adding a Person

This page is where everybody is created — it's the only Add person form in CleverOps.

Click Add person (requires the Manage team capability). The form asks three questions:

1. Which control-room apps do they use? Tick CleverResponder, CleverCommand, both, or neither:

Tick	What it means
CleverResponder	An armed response officer or patrol driver you dispatch. Signs in with a 15-minute one-time code (or their own email and password, if their account is linked), and appears on Response.
CleverCommand	An operator who monitors and dispatches. Signs in with a login code + PIN (or their own email and password, if their account is linked), and appears on Control Room.
Neither	Somebody who never signs in — a static guard or office staff. They still need a record here for PSIRA, contracts and documents.

There is no "what are they" question: the app is the answer. Both ticks can be changed at any time from the Access column on this page, or under Roles & access on the person's workspace.

Are they a guard? (only where the Roster module is enabled) — No, Permanent or Casual. Answering Permanent or Casual seeds their profile with the classification, so they land on the Guards tab and the Roster's guard views. Changeable later on their profile.

2. Do they use the field apps? Answer Yes to give them the CleverTech sign-in. Whether they can be assigned work is a separate choice — the duties below. Independent of the first answer: an office manager can carry the app too.

Pick their field duties here — Technician (assignable to jobs, shows in Team load and the job pickers), Sales (adds CleverSales and the sales-rep pickers), both, or neither. Nothing starts ticked, and nobody becomes a technician by default. Leaving both unticked is a deliberate state — app access only: they can sign into CleverTech but appear in no technician or sales list, which is the right shape for an owner or manager who only views jobs. Setting duties needs the Manage roles capability; without it the only shape you can hand out is Technician, and the form says so. Either way the duties can be changed afterwards under Roles & access on their workspace, or from the Manage button on their row.

3. Do they also sign in with an email and password? Independent of both answers above, because one person can have all three. Answer Yes, enter their address and pick their roles in this workspace. The roles start out following question 2 — somebody on the field roster is pre-ticked with those same roles in CleverOps; anybody else starts with nothing ticked, and the form insists on at least one (an email sign-in with no role opens nothing; Auditor is the read-only floor). Then:

• They already have an account → it's attached and the two records are linked automatically.
• They don't yet → an invite is created and emailed to them. The confirmation screen shows the link for copying and an Also send it on WhatsApp field — enter their mobile number and Send on WhatsApp to send the same link there too. They join with the roles you picked once they sign up with that email and open it, and their new account is attached to the person record you just created — so they stay one row on this list rather than appearing a second time as an account of their own. Until then the invite sits under On their way in, which shows how far they've got.

Only company owners and admins can grant email sign-in. Anyone with Manage team can still add the person; an owner or admin can add their account afterwards from the profile. The Administrator role is the one exception — only an owner can pick it, because it makes the person a company admin.

Once saved, their profile opens so you can capture PSIRA, ID and contact details while it's fresh.

Attaching somebody who already has an account

Picking the email of an existing team member replaces their roles on this workspace and locks their other workspaces. If they currently have full access, that's a downgrade. The form warns you and pre-ticks their current roles, so leaving the roles untouched keeps their access as it is.

An email address can back only one person per control room. If it's already in use on this list, the form says who has it and blocks the duplicate rather than creating a second record for the same human.

The workspace, tab by tab

The header line names the person, their job title and their company role where they hold one — Company owner or Company admin — because that outranks everything below it; under it, their Command role, the seat's tags, and quiet links Open in Response ↗ / Open in Control Room ↗ where the person has that app access (they land on those lists — neither page has a per-person link). Then these tabs:

• Person — full name (saving it writes the seat label too, so the two stop drifting), job title, job class (what the company pays them as — People → Config keeps the list), Employee / clock number (what a clock file names them by), ID number (a SA ID / Passport / Other dropdown in front of the number; an SA ID is checked in full, and any number already captured on somebody else in the room is flagged -- both warn, never block), gender, EE category, Disability (Not asked / No / Yes — self-declared, for the EEA2 count), languages, phone, email, physical address, transport mode and home suburb, start date, emergency contact, and free-form notes. Where the Roster module is on, a Guard field classifies the person as Permanent guard, Casual guard, or Not a guard — this is what the Guards tab lists — and Rosterable overrides the default rule.
• Roles & access — their seat in each room, its roles and app access, the per-room company-admin stamp, and how that seat signs in (codes, PIN, email account). See Roles & access above.
• Field work — roster membership, hourly rate, working hours and days, specialisations, regions, commission and time off.
• Roster (where the Roster module is on) — the roster side of the one record: the Roster link (create & copy, reissue, revoke — it lives the room's number of days and shows its number of weeks), the person's Pay rate (the rate in force today and where it comes from — own, class, or the class's legacy rate — with Add a rate for this person from a date; a person's own row beats their class's), Written agreements (overtime, averaging, compressed week…), Site & post preferences (preferred / banned — a row covers a whole site or one single post, so units and desks are included; a ban carries its source, a reason and an optional review date, and is set on each post's sheet on the Roster's Posts tab), Kinds of work (fixed sites / ad-hoc shifts / units / desks — untick a kind and the Fill, the offer waves and the roster link's claim board all skip this person for it), and Absence on record with the decisions. Shifts, hours and the board live on the Roster page — Open on the Roster ↗.
• Conduct (where the Roster module is on) — the disciplinary record: occurrence → warning → hearing → outcome → appeal. See Conduct below.
• Compliance — PSIRA, firearm competency, driver's licence, contracts, ID documents, training and medicals. See below.
• Academy (where the CleverCam Academy module is on, for people with Manage team) — what the person is enrolled in, their progress and certificates, and Enrol in the Academy for just them. See Academy.

Opening a workspace requires the Manage VCR capability — it is never visible to, or editable by, the people themselves.

The same workspace opens from Response → Responders and from Control Room, so a person looks the same whichever door you came in through.

The Compliance tab: one record, one expiry, one document

An expiry and the certificate proving it are the same record. Each entry on the Compliance tab carries what it is, its number where it has one, an optional expiry date, and an optional document.

Both halves are optional, deliberately:

• A date with no document. "PSIRA expires in March, the certificate is still with the printer" is a real state. Capture the date now and press Attach when the paper arrives.
• A document with no date. A contract or an ID copy never expires; it just lives here.

Each dated entry shows a colour-coded chip — amber inside the kind's warn window, red inside its critical window or once overdue (the windows live on the kind under Settings → Reminders → What can expire: 60 / 14 days for PSIRA, 90 / 14 for firearm competency, 30 / 7 for a licence) — and feeds the weekly reminder email and the dashboard's Expiring soon section. Because the date and the document are one record, a renewal is chased once, never twice.

Once you've applied for a renewal you can record the reference on that entry, so the reminder reports it as in hand instead of chasing it — see Recording a renewal application.

Checking a PSIRA registration against the register

At the top of the Compliance tab sits the PSIRA register strip. Click Check with PSIRA and CleverOps looks the person up on the regulator's register — by the PSIRA number on file, or by the 13-digit ID number on the Person tab if there is no PSIRA number yet (there is also a box to type a PSIRA number straight into if neither is on file).

It is a two-step check, on purpose:

1. A dialog shows what PSIRA says — name, PSIRA number, ID number, status, grade, expiry, current employer, registration date — next to what is on file. Read the name. A mistyped ID can match a real other person.
2. Confirm & lock writes PSIRA's record: the grade, status, expiry and employer go onto the PSIRA entry; the ID number is filled in from PSIRA if the Person tab had none; and both the PSIRA number and the ID number are locked. From then on neither can be edited, and the PSIRA entry cannot be deleted — not by anyone in your company. Only CleverCam support can unlink a verification, so ask before confirming if you are not sure it is the same person.

Newer registrations don't show an ID number. PSIRA's record for registrations from about 2024 onward carries an application reference (APP-…) where older ones show the person's ID number. When a search by ID number finds exactly one such registration, the dialog still shows it: the ID number reads (searched) in the PSIRA column, with a line under the table saying PSIRA's record does not show it. Confirming links the registration and locks the ID number you searched with, the same as any other check, so be sure the name is this person first. If the ID search finds more than one registration, CleverOps doesn't guess and reports nothing found.

If PSIRA's record disagrees with a number already on file — a different PSIRA number, or a different ID number for that PSIRA number — nothing is written. The dialog says which number differs; correct the one on file and check again, or contact CleverCam support if it is the verified one that is wrong.

Once verified the strip shows ✓ Verified with PSIRA with the date, PSIRA's status, grade and employer, and the entry in the list carries a ✓ verified mark. Re-check refreshes status, grade and expiry from the register — the number itself never changes on renewal — and is the only way to touch that entry afterwards. The expiry that lands here is the one the weekly reminder email and the roster's eligibility checks use.

Every check is recorded: who ran it, about whom, and what came back. Each lookup is for one person, and a person can be checked a handful of times an hour at most. To work through a whole control room, use Check everybody with PSIRA on People → Compliance — it runs this same two-step check down a list, one person at a time and a few seconds apart, and still asks you which rows to lock.

Status is shown, not judged

If PSIRA returns a status other than Registered — suspended, withdrawn, expired — the identity is still verified and locked; the status is stored and shown on the strip so it can be followed up. CleverOps does not decide what a non-registered status means for that person's employment.

Renewing keeps the old one

Adding the same kind of thing again does not overwrite what was there. The new certificate becomes the current one, and the previous sits under Show previous as history. Reminders, chips and roster checks all follow the current one, so a superseded certificate can never nag you or block a shift.

Adding your own kinds

The list you pick from is not fixed. If you track something the standard list doesn't cover — a first-aid level, a control-room certificate — add it under Settings → Reminders → What can expire. It appears on every person from then on, and it needs no help from CleverCam.

Conduct: the record a hearing asks for

Every occurrence a supervisor records against a shift (Roster → Attendance → Record occurrence…) already lands on that shift's ledger. The Conduct tab on the person's record is what ties those to a case: occurrence → notice → hearing → outcome → appeal → the CCMA, each step with its date and who recorded it, appended and never edited.

• What still counts leads the tab: the warnings that are still live, the highest of them, open cases, and — muted — the ones that have lapsed. A written warning stops counting after the room's window (Roster → Config → conduct warning months, six by default, the Code of Good Practice norm); counselling and a dismissal never expire. This is the only reading progressive discipline should be argued from — an expired warning is not a step on the ladder, and the page says which step would come next without recommending that anybody take it.
• Open a case… takes a summary (required), the occurrence code it falls under, the date it happened, and may cite the shift occurrence it came from. Then the steps, in whatever order they really happened: Serve notice, Set a hearing (the room's hearing notice days is shown as the minimum), Hearing held, Record the outcome (the level and what was decided), Appeal lodged, Appeal outcome, Refer to the CCMA, CCMA outcome, Withdraw, or a plain note. Recording an outcome closes the case and sets when the warning stops counting; an appeal outcome can lower it. A withdrawn case counts for nothing.
• The case's state and level are never typed in — they follow the steps, the way a shift's evidence grade follows its ledger.

Leave: what each person has left

People → Leave is the balances the rules produce. The rules themselves are under Config (seeded from the Main Collective Agreement and the BCEA); this tab is what each person has accrued, taken and has left, on a date.

• Pick the kind — Annual · Sick · Family · Study — and the tab lists every rosterable person: the cycle, entitlement, accrued, carried, taken, pending and the balance. Each kind is counted in its own unit: annual leave in calendar days, sick leave in shifts. The two never convert, by law, and nothing here pretends otherwise.
• The cycle is the person's own, not the calendar year: twelve months from their start date (BCEA s20(2)), thirty-six for sick leave (s22(2)). Annual accrues month by month through the cycle; sick leave in the first six months accrues at one day per 26 days worked and only then becomes the full six weeks. A person with no start date on file falls back to the calendar year, and the tab says so, because that is a records gap somebody should close.
• Carried and forfeited — annual leave only. What last cycle left of a person's annual leave is carried with the date it dies (the room's take within months after that cycle ended) and counted in the balance until then; after that it is gone, which is what the agreement says and what a payroll query will ask about. Sick, family and study leave do not carry — each cycle stands on its own — so those columns read "—" and that is the law, not a gap.
• Taken is read off the one absence ledger (approved rows only), counted off real shifts where the roster has them and off the calendar where it does not; pending requests are shown apart and never in the balance, so approving one is a decision made with the number in front of you.
• Opening a person's row shows every kind, the accrual in a sentence, and their adjustments — an opening balance carried in from another system, a correction, a payout — each with its reason. Add an adjustment takes days (plus or minus), a date and a reason; everything else on the tab is computed, so an adjustment is the only place a number is ever typed in.

Compliance, across everyone

The People page's own Compliance tab has two views. Everyone by credential — one row per person, one column per kind anyone holds or is short of, each cell the sub-category, the expiry and its state (lapsed · critical · expiring · missing · ok, worst first), filtered by working group (Everyone · Guards · Reaction · Control room · Other) and by state, exportable as a CSV; a row opens the person's record on its Compliance tab. Tracks — the enrolment-based compliance tracks, which have their own page: Compliance. Missing is only claimed where it matters: PSIRA for guards and reaction officers, firearm competency for people in an armed job class. The roster reads the same record — its readiness rail, Fill and offers say firearm competency: handgun expired 2 Aug, never a bare "not qualified".

Checking a PSIRA registration against the register

PSIRA is the one credential with a register to check it against, so it is the one that can be answered from CleverOps rather than only recorded. A check asks PSIRA's own register for the person's entry — by the PSIRA number on file, or by their 13-digit ID number where that is all you hold — and shows you what came back next to what is on file. Nothing is written at that point.

Confirming is the second step, and it does two things at once: it writes PSIRA's grade, status, expiry date and employer onto the person's PSIRA entry (filling in the ID number if it was blank), and it locks the PSIRA number and the ID number. Locked means locked — the database itself refuses later edits to either, from any screen, and only CleverCam support can unlink a verification.

That is why there is no one-click path from a list straight to a lock. A mistyped ID number matches a real other person, and confirming it would freeze the wrong human onto an employee's record permanently. Every route below shows you PSIRA's name before anything is written.

Three routes to the same check:

• One person, from their record. Open them → Compliance → the PSIRA register strip at the top → Check with PSIRA. Once verified the strip becomes a green ✓ Verified with PSIRA badge with the grade, status and employer, and the button becomes Re-check — which refreshes the grade, status and expiry after a renewal. The number itself never changes on renewal.
• One person, from the list. On Everyone by credential, a PSIRA cell is itself clickable: it runs the same two-step check without leaving the table. A 🔒 after the date means that person is already verified and their numbers are locked; clicking re-checks them. Cells sit on rows where there is something to look up with — including somebody showing Missing, if they have an ID number on file for PSIRA to be searched by. The rest of the row still opens their record.
• Everybody, or whoever is on screen. Check n with PSIRA in the toolbar of Everyone by credential (and Check everybody with PSIRA on the statutory track under Tracks). The count is how many checks it is about to spend.

The sweep is two passes, not one. Check previews everybody you ticked, one person at a time a few seconds apart, writing nothing; each row fills in with what PSIRA holds beside what is on file. Confirm & lock then writes only the rows you tick afterwards. What is ticked for you is the whole safety argument:

PSIRA's answer	Ticked for you?
Confirmed the PSIRA number already on file, and the names agree	Yes — we asserted that identity long ago; the register only confirmed it
Returned a registration we did not have, found by searching the ID number	No — read the name first
Returned a name sharing no word with the name on file	No, and flagged name differs

Opening the sweep from Everyone by credential starts on whoever the filters had on screen — filter to Reaction · missing, press the button, and only those people are ticked. Two chips beside it widen the run to everyone not yet verified, or to everyone with something to look up with.

A control room may spend 600 checks a day, and any one person may be looked up 6 times an hour; the screen shows what is left before a run starts, and skips anybody it already knows would be refused. Runs are paced deliberately — one person at a time, a random few seconds apart — and stop on their own after three failures in a row. Both passes are recorded, so a sweep can be traced back afterwards.

All of this needs Manage VCR. Without it the PSIRA column is read-only like every other.

Config

The last tab, the way Billing keeps its reference data, for the things every person has — not only guards. Seeded, so nothing here has to be opened before the roster runs:

• Job classes — what the company pays a person as and what a cover line asks for (EasyRoster's "grades"): the rule set decides the ordinary week (NBCPSS 48 h or BCEA 45 h), the pay basis (per shift, per hour, monthly), the PSIRA minimum and the armed / dog flags the line inherits, and the EE level — the EEA2 occupational level the class reports under. Add, edit, retire. A class's rate is a dated row on Roster → Config → Rates & allowances.
• Absence kinds — letter, name, category, whether it pays, and the unit it is measured in — annual leave in calendar days, sick leave in shifts, by law; the two never convert.
• Leave rules — the entitlements per rule set, NBCPSS (guards) and BCEA (everyone else): annual leave, the extra days after years of service, sick leave per cycle, family responsibility, study leave, and how long leave may be carried. Seeded from the Main Collective Agreement and the BCEA (the Law pill); Edit only if the company gives more (Room's own), Back to the law undoes it. These are the rules; the balances they produce are on Leave.
• Occurrence codes — what a supervisor can record against a shift from Attendance (absent, late, desertion, sleeping, under the influence, failed check calls, uniform, left early); each is an event on the posting's ledger.
• Rosterable rule — who the roster may place by default, and how many people carry an override.

Linking a person to their email account

There is no picker. Choosing an account from a dropdown put a merge of two unrelated humans one stray click away — the wrong person would inherit the other's compliance record — so an account is attached by an invite the person accepts themselves:

1. Open the person, go to Roles & access, and find the Email account card under the roles.
2. Enter their address and click Email an invite — or add their mobile number and click WhatsApp an invite to send the same link that way (it falls back to SMS when WhatsApp can't reach them, and says so).
3. The card now shows the invite itself — the same card as On their way in, with its Sent → Opened → Signed up → Accepted line and Resend email, Send on WhatsApp, Change email, Copy link and Revoke. It is still there when you close the person and come back, for as long as the invite is open.
4. They open the link. The page tells them who invited them, to which company, as what, and which address the invite is for. If that address has no account yet, Create account is the main button and the sign-up form arrives with the address already filled in and locked, so they can't sign up on the wrong one; if it has, Sign in is the main button. Either way they come straight back to the invite afterwards.
5. Back on the invite they see what accepting does, with Accept invite and Not now. Opening a link never joins anybody on its own — accepting is a deliberate click. Signed in as the wrong account? The page says which address the invite is for and which one they're on, and offers Sign out and switch account, which brings them straight back to the same link.

A link that can no longer be used says why straight away, before anybody signs up for nothing: expired (ask the inviter to send it again — the same link then works), withdrawn, or not valid any more — which is what the old link says after you Change email.

Somebody who creates an account on the invited address without using the link isn't left guessing: the control-room selector and the Create Company screen show a notice that ‹inviter› has invited you to join ‹company› and to open the link in their email or WhatsApp. The notice can't accept for them — the delivered link is what proves the mailbox is theirs.

Accepting attaches their account to this person record, so they stay one row on this list. If they're already a member of other companies, those are untouched; the new one simply appears in their control-room selector. An account they created through one of the mobile apps works too — the invite matches on the address, not on where the account was made.

The person proves the address is theirs by opening it — the one check a dropdown could never make. Attaching an account never changes their app access or codes; it only records that these two records are the same human.

They join read-only

An invite raised from this card grants Auditor (read-only) — reports and the audit trail, nothing writable. It has to grant something: every role carries at least one capability, so there is no "invite with no access" option. Give them what they actually need with the role chips above once they've accepted.

If the address already has a CleverOps account, there is nothing to invite — the card says so and offers Attach account to ‹name› instead, which stamps that account onto this person on the spot (owner or admin only, and only if the account isn't already on another record in this room — that case is a duplicate to merge or remove, not to link).

Only company owners and admins can invite or attach; anyone else with Manage team sees the card read-only, with the reason.

To move somebody onto a different account, remove them from the company and invite them again. That is deliberately awkward, because merging two people is not something to do by accident.

Getting a login doesn't create a second you

Somebody who has been on this list for months with no login is already a person in CleverOps. When they accept an invite, their existing record picks up the account — they don't become a new, second person with an empty history. Nothing to do; it just happens.

If the account is somehow already claimed by a different record in the company, CleverOps leaves both alone rather than picking one, and lists the pair under Possible duplicates for you to sort out.

People who may be the same person

The same human can be recorded twice — added in two control rooms, added twice in one, or once as an operator record and once as the account they signed up with. It mostly happens to people with no login on one of the records, because an account is proof of identity and a name is not: two records called S. Nkosi might be one person working two sites, or two different people. CleverOps will not guess, so it keeps them separate until somebody who knows says otherwise.

When there is something to look at, a Possible duplicates button appears next to Add person. It is owner and admin only, and it is company-wide — not just this control room — because that is where duplication happens.

Each pair shows both records side by side with everything you need to tell two humans apart: which room each seat is in, which apps it opens, and the seat's job title, employee number, ID number, phone and start date. Pick which record to keep, then Review merge….

Two seats in the same room

The commonest pair is two seats for one person in one control room — typically a code-login operator seat and the account seat created when the same person became a company admin. Both records sit in the same room, and the card says so.

Understand what a merge does here before choosing it. A merge joins the two person records but never touches seats — so after merging, the person still holds two seats in that room, and the People list, which is one row per seat, still shows two rows for them (each marked 2 seats for this person here, so nobody reads them as two humans). Each seat keeps its own codes and app ticks.

So:

• If one of the two seats is plainly unused — no code login, no account, no history — don't merge: Remove that seat from the People list. The spare person record disappears with its last seat, and the pair is gone.
• If both sign-ins are in use, merge — the compliance history joins — and keep both seats. The confirmation names the room and says the two rows will remain.

What a merge does — and what it doesn't

The confirmation spells out both, and you must tick to confirm before the button works.

It does: move the other record's seats onto the person you're keeping, and stop the duplicate being a separate person. If only one of the two had a login, the surviving record keeps it.

It doesn't touch the seats themselves. App access, login codes, PINs, duty and shift state, dispatch history, vehicle checks — all of it stays exactly where it is. Nobody gains or loses access to anything. Merging says these two records are one human; it never merges or deletes the roles they hold.

Two rules are enforced no matter what you tick:

• Never across companies. A person record belongs to one company.
• Never two real accounts. If both records hold their own CleverOps login, that is two humans, and CleverOps refuses.

Placeholder names are kept separate

Unfilled seats often carry names like New Responder or Controller 2. Several of those matching each other means nothing, so they are counted and offered under Show them anyway rather than mixed into the real list — a list where every row is a false alarm is one you stop reading.

History and undo

The History tab records every merge: who did it, when, how many seats moved and the reason they gave. Each one has Undo, which brings the separate record back with its seats.

Undo is refused, with the reason shown, if a seat has since moved on to somebody else — unpicking would take it from them.

Removing a Person

Open the person (click their row) and, at the foot of the Person tab, click Remove from this control room in the Danger zone. (Someone who can't open workspaces sees a Remove button on the row instead.) This removes their seat in this control room — not the human. The confirmation names the person and states exactly what goes with the seat: their profile, uploaded documents, and their history of events handled, positions reported and vehicle checks bypassed. Login codes stop working.

What survives, and the dialog says so:

• Seats they hold in other control rooms. You can see them under Roles & access on their workspace before you remove anything.
• Their field-roster row, which comes loose from them and reappears on this list on its own.
• Their email account, untouched.

Two things go with the seat that are easy to miss, and the dialog names both:

• If this was their last seat anywhere (and they are not a company owner), the person record goes too — there is nothing left for it to describe. This is also what makes Remove the clean fix for a duplicate seat: the spare record does not linger as a "possible duplicate".
• If the seat carries their company standing — company admin or member — removing it takes away their CleverOps access in this control room, because standing lives on the seat.

Most people cannot be removed at all

Anyone who has been dispatched, crewed a unit, or logged a vehicle check, trip or fuel entry cannot be deleted — their history is referenced elsewhere and deleting them would break those records. CleverOps says so plainly instead of showing a database error. For those people, untick their app access in the Access column instead: that takes the app away and leaves the history intact.

Removing a roster-only row

A row with no seat — a field-roster entry left behind by an import, or one added twice — has its own remove: click Manage on the row and use Remove roster row in the Danger zone at the bottom. It deletes the field-roster row itself, so the entry comes off this list for good. (Take off roster, under the row's Manage button, only marks the entry inactive — it stays on this list.)

The same Danger zone sits under Manage for an account holder who has a field-roster registration but no seat here. For them, Remove deletes only the roster row — their account, seats and CleverOps access are untouched, and they stay on this list; the confirmation says so, and points at Take off roster as the softer alternative.

What the delete does, and the confirmation spells out:

• Job history is kept, but unlinked. Jobs the entry was assigned to stay on record with their assigned-technician link cleared, and the name comes off per-job crew lists.
• A row that has recorded trips as a driver cannot be removed — driving history keeps its driver, and CleverOps says so plainly instead of showing a database error.

The Danger zone is offered with the Manage team capability; the delete itself also needs service-management access in this control room, and CleverOps says so if it is refused rather than reporting success over an untouched row.