When someone leaves: revoking access

When a colleague leaves or moves on, you revoke their access by deactivating them — not by deleting. A deactivated account cannot sign in, but their logs, the events they reported and their audit trail are kept, and the account can be restored at any time. This is not a convenience decision: a closed shift diary must not lose its author just because that person no longer works with you.

Before you start

Permission: the role-management right — roles:manage.
Where to find it: the Access → Users tab; the ⋮ menu on the colleague’s row, and the Deactivated colleagues card below.
Not here: deleting your own account — that lives under Account → Danger zone (see below).

Steps

Open the Access → Users tab.
Find the colleague and open the ⋮ menu at the end of their row.
Choose Deactivate. The system asks for confirmation and says exactly what will happen: “Deactivate …’s account? They will no longer be able to sign in. Their logs, reported events and audit trail are KEPT (ISO 45001 requires this), and the account can be restored at any time.”
Confirm. The colleague moves to the Deactivated colleagues card at the bottom of the page.
If they come back: in the same place, the row’s ⋮ menu offers Restore — the account continues with its previous role.

The Deactivated colleagues card at the bottom of the Users tab: the explanatory text, then the rows of deactivated accounts with email and role, and the Restore action at the end of each row. — The **Deactivated colleagues** card. Anyone listed here cannot sign in — but everything of theirs is intact, and one click restores them.

Two kinds of ending — and the difference matters

	Deactivation (done by an admin)	Account deletion (done by the user THEMSELVES)
Who starts it	an admin, on the Users tab	the colleague, under Account → Danger zone
Sign-in	revoked (from their next request)	revoked, permanently
Logs, events, audit trail	kept	kept (required by law)
Restoring	one click	only with a new invitation
Where it shows afterwards	on the Deactivated colleagues card	nowhere — “Accounts users deleted themselves do not appear here: that is permanent.”

The Danger zone on the Account page: the explanation that deletion is permanent and the audit trail is retained, then the confirmation checkbox and the delete button. — Deleting your own account under **Account → Danger zone** — behind its own confirmation tick, because this **cannot** be undone.

If it worked

The colleague appears on the Deactivated colleagues card and cannot sign in from their next request. Their earlier logs, events and audit trail are untouched — a closed diary still has them as its author. The action itself also leaves an audit trace: who revoked the access, and when.

Common problems

What you see	Why	What to do
No ⋮ menu on the row / no Deactivate	You do not have `roles:manage` (viewing the roster is a narrower right).	Ask your admin.
“You cannot deactivate the last Administrator…”	The workspace would be left without an owner.	Appoint another Administrator first, then repeat.
The colleague can still sign in	The lock-out takes effect from their next request — an already open page may still show the old state.	Nothing to do; they are locked out on the next load.
I cannot find the deactivated colleague in the list	Either they are not deactivated, or they deleted their own account (that disappears from here permanently).	If access has to be given back, send a new invitation.
I wanted to delete, but I can only deactivate	There is no hard delete for admins — deliberately.	Deactivation is the correct action; deletion can only be the user’s own decision.

Worth knowing

Why no deletion? A hard delete would orphan the audit trail: closed diaries, events and acknowledgements would lose their author. Traceability under ISO 45001 §10.2 is exactly what forbids this.
GDPR does not demand a hard delete where a legal retention duty exists — which is why the app takes the “sign-in ends, the trace stays” route. Deletion requests are handled per the privacy notice.
With multiple sites revoking access can be partial: if the colleague only leaves one site, it is enough to untick their site access on the Users tab — no need to deactivate the whole account. See Basics: sites, plants and who sees what.
The worker roster is a different thing. Names in the Roster are not OPEREX accounts — you archive a departing worker’s name there, which affects the attendance list, not sign-in.

Invite a colleagueThe opposite — and the way back for revoked access.

Custom roles and the permission matrixWhen you want to narrow access rather than remove it.

Basics: sites, plants and who sees whatWith multiple sites, removing site access may be enough.