Four screens under Settings, and they are four different questions that get confused with each other constantly:
| Screen | Answers |
|---|---|
| Users | Who can sign in |
| Employees | Who works here, in what position |
| Roles | What a kind of person may do |
| Groups | Which people are that kind of person |
Chapter 13 covered where somebody's access reaches — organisation units and scope. This chapter is what they may do and who they are. The two are genuinely separate: a permission says what, a scope says where.
Users and Employees are not the same list
This is the distinction that trips up every new administrator, so it comes first.
- A User is a login. It has an email, roles, and a state — active or deactivated.
- An Employee is a person in the organisation: a position, an organisation unit, and — for exactly one of them — the billing account.
A contractor with a login and no position is a User and not an Employee. A person on the staff list who never signs in is an Employee and not a User. Most people are both, which is why the two get confused.
Employees carries the billing account, and only one person holds it at a time. Invoices are sent to them. Deactivating that person clears the designation — the screen warns you, and it is worth reading, because "we stopped getting invoices" is a slow, quiet failure.
Users — invite, deactivate, delete
Settings → Users.
- Invite somebody by email. They accept and set their own password; you never handle it.
- Deactivate removes access immediately. The account remains and can be reactivated at any time, with its previous roles.
- Delete cannot be undone, and the confirmation says so.
Deactivate is almost always the right one. A person who leaves and comes back, an account under investigation, a contractor between engagements — all of those keep their history attached to something that still exists. A deleted user leaves audit entries pointing at somebody who is no longer there.
Bulk actions handle the whole selection: activate, deactivate, delete. Two things about the bulk path worth knowing:
- Administrators are skipped on deactivation, individually and in bulk. The product refuses to let you lock every administrator out of the workspace by selecting all and clicking once.
- When some rows are skipped, the result says "Deactivated 4 of 7" rather than reporting success. Read the number.
Roles — permissions, not people
Settings → Roles. A role is a named set of permissions. Users get roles; users do not get permissions directly.
Each role shows its type, the domains it touches, and how many permissions it carries.
- Protected roles cannot be deleted. These are the ones the platform depends on; the delete simply refuses and says why.
- Duplicate copies a role as "{name} (copy)". This is the way to build a new role: start from the closest existing one, then take permissions away.
Build roles by subtraction, not addition. Starting from an empty role and adding permissions until somebody stops complaining produces a role nobody can describe. Starting from a role that works and removing what this person should not have produces one you can explain in a sentence.
The blunt test, from chapter 9: can the person who assembles a case approve it? If a role carries both, your approval chain records people agreeing with themselves. Approving is a different permission from editing, and this is the screen where that stops being an abstraction.
Groups — so the roles stay few
Settings → Groups. A group is a set of users that carries roles.
The reason to use them is arithmetic. Forty people and six roles assigned individually is two hundred and forty decisions, each of which can be wrong and none of which is visible from anywhere. Six groups carrying six roles is six decisions, and "who has this?" becomes a list you can read.
Each group shows its type, its members and its roles.
- System groups cannot be deleted, the same way protected roles cannot.
- Duplicate works here too, and for the same reason: start from one that works.
When somebody's access is wrong, fix the group, not the person. A per-user exception is invisible six months later — it is the row nobody thinks to look at, and it is how one person ends up with access nobody intended and nobody remembers granting.
Where the boundary with chapter 13 falls
It is worth being explicit, because these two chapters are the pair people mix up:
- Roles and groups decide what somebody may do — view, create, update, delete, approve.
- Organisation units and scoped access decide where that reaches — which branch, which department, and whether the grant descends the tree.
Both must be right. A person with the approval permission and no scope over the Porto branch cannot approve a Porto case, and the reason will look like a bug until you know which of the two is missing.
Addenda follow the matrix's unit. Adding to a completed Dossier is a permission of its own, Create an addendum to a completed dossier, which the Contributor role carries, as do the organisation's owner and administrators. Its where is the organisation unit of the Dossier being added to — not the person's own unit, and not the unit where the addendum will be worked. Nor is it the same as adding Documents to a Dossier still in progress: that adds to a live case, while an addendum adds to one that is already closed, without reopening it.
What you should have now
- Users invited, and a rule that leaving is a deactivation rather than a deletion.
- The billing account set on a person who is not about to leave.
- Roles built by duplicating and subtracting, each describable in one sentence.
- Groups carrying the roles, and no per-user exceptions you cannot justify out loud.
- One person checked end to end: their role says what, their scope says where, and both are what you meant.