User Accounts
An account is how somebody signs in and what the platform attributes their actions to.
Where to find it
Architect Panel → Security:
- Disabled User Accounts — accounts closed administratively
- Blocked User Accounts — accounts banned after failed sign-ins
- Permissions — what a group grants
User accounts and groups live in the Admin Panel sidebar under User Administration — All Users and User Groups. What a group may reach is granted in the Architect Panel.
An account is an identity, not a person
The distinction that explains most confusion. Identity is recorded as three parts — the sign-in method, an identifier within it, and a domain — so the same human arriving by password and by single sign-on is two identities.
That is deliberate: it lets the audit trail distinguish "Jo signed in and did this" from "an integration acting as Jo did this". It also means "I already have an account" can be true and irrelevant.
The account is not the access
An account by itself reaches almost nothing. Access comes from group membership, and group membership is a separate decision.
So creating an account is not granting access, and disabling one is not the only way to remove it — worth being precise about, because people conflate the two constantly.
Settle the lifecycle early
Most organisations plan joiners and discover the rest:
- Joiners — usually handled.
- Movers — rarely. People are added to new groups and left in old ones, accumulating access from every role they have held.
- Leavers — handled for directory-backed accounts, frequently not for local ones.
- Dormant accounts — almost never. Self-registered accounts in particular accumulate indefinitely.
The mover case is the one that shows up in every access review, and it is entirely preventable by making removal part of the same task as addition.
Local accounts need the most attention
They are outside your directory's joiners and leavers process, and they are disproportionately privileged, because local accounts tend to be the ones created for administrators and emergencies.
Keep a list of every local account, who owns it and why it exists.
Never share an account
It destroys attribution — the audit trail records the account, and the account is not a person — and it trips account banning constantly, because one person's failed sign-in counts against everybody.
Where a task genuinely needs an account rather than a person, that is a service identity with its own credentials, not people sharing a login.
Disabling is better than deleting
A disabled account keeps its history intact, so records still say who did what. Deleting one leaves an audit trail referring to somebody who no longer exists.
Worked example
An organisation runs directory-backed accounts for staff and eleven local accounts, each with a named owner and a reason. Group changes are part of the movers checklist, so a role change removes old memberships as well as adding new ones. The annual review found nobody holding access from a previous role.
Recommendations
- Handle movers, not just joiners and leavers.
- Inventory local accounts and review them.
- Never share an account — use a service identity.
- Disable rather than delete.