Staff roles and permissions: who can see what
A role decides what a token can reach across the whole platform. Granting or revoking one is a single deliberate act — there's no draft, and no batching.
The staff roles screen looks like a settings pane and isn't one. Every checkbox on it is an authority: granting a role widens what its holder's token can reach across the entire platform, and revoking one narrows it immediately. That's why there's no Save button here and nothing is batched — each change is applied the moment you make it, as its own deliberate act.
What a role actually controls
A role decides which scopes a signed-in staff member's token carries. Those scopes expand to specific, dotted permissions — desk.conversation.take, rules.arnona.publish — in memory, on the server, per request. There's no permission lookup against a database on every call; the token already says what it says, which is exactly why granting or revoking a role has to be an explicit, auditable act rather than something that could drift.
Zero roles means zero access, not default access. An account with no role assigned signs in successfully and reaches nothing at all — narrowing by role fails closed, the same discipline that runs through every other gate in this platform.
Two rules the server enforces, and this screen only reflects
- You can't hand out authority you don't hold yourself. Unless you carry platform-level authority, you may only grant a role that's already among your own. This is computed server-side on every write, not assumed from what the screen happens to show you.
- Self-assignment and self-revocation are both refused, in either direction. You can't grant yourself a role, and you can't take one away from yourself either — a rule that exists so a compromised account can't quietly widen its own reach or erase evidence that it once had less.
A refusal from either rule comes back as a real message key naming which rule fired, not a generic error — because an operator can act differently depending on which of the two it was.
Roles and desk clearances are two different things
A role decides scope-level authority across the platform. Which specific conversations an agent's desk queue actually surfaces to them is a separate, department-level clearance, configured on the desk staffing screen rather than here. Someone can hold a role that grants desk access in principle and still be clear to see only their own department's queue — the two controls are independent on purpose.
Before revoking a role from someone leaving a position, check what they can currently reach through the desk clearances screen too — the two aren't tied together automatically, and closing one door doesn't close the other.