Access reviews and offboarding
Review access as a combination of account state, roles, capability availability and operating scope. One screenshot of the Users list cannot establish all of these.
Recommended review record
| Question | Evidence to inspect |
|---|---|
| Is this still the correct person/account? | Username, email and enabled state |
| What can they do? | Complete role set and each role's complete permission set |
| Where can they work? | Business-unit grants and primary unit |
| What can the tenant use? | Entitlements, module/feature configuration and runtime state |
| Are specialist restrictions involved? | Care facility/caseload/health/safeguarding controls or other domain rules |
| Who approved the change? | Your internal request/approval record; relevant saved metadata |
Move a staff member
- Confirm the destination duties and units.
- Compare existing roles against the new responsibilities; do not merely add new access indefinitely.
- Replace the role set with the reviewed final set.
- Update unit selections and the selected primary unit.
- Reload both assignments and verify fresh sign-in.
- Test one intended action and one formerly allowed action that should now be refused.
Offboard an ordinary user
Use the authorised account edit to disable the user when required by your approved process. Separately hand over open orders, approvals, cash responsibilities or other domain assignments. Disabling a login does not transfer ownership of documents or finish outstanding business work.
The unit-access screen lists enabled users and requires at least one selected unit plus a primary to save. It is not a complete “remove all access” offboarding wizard. Do not describe Clear All as a successful full-revocation action. Resolve any required grant cleanup through an authorised supported procedure.
For owners, use operator ownership replacement/recovery rather than trying to demote or disable SUPER_ADMIN in tenant Users. A protected account has stronger rules than ordinary offboarding.
Session and audit checks
Role/permission changes invalidate affected authorization sessions; ask users to sign in again. Do not accept an old open menu as proof that a removed permission still works. Reload the actual action and distinguish a stale browser view from a successfully authorised request.
Capability configuration exposes version and actor/timestamp metadata. Appearance has publication history. Platform operator actions have a separate platform audit. These are distinct records; the guide does not claim a unified exportable administration audit/report screen exists.