Suspending, offboarding and deleting a user

Somebody has left, or is about to. This article says what each of the available actions actually does to their account, in what order, what you can reverse and what you cannot. Choosing wrongly is expensive in both directions: too gentle and a working login walks out of the building, too harsh and you destroy the record you will need in six months.

The single most important fact in this article: suspending, locking or disabling an account immediately ends every session that account holds, everywhere, and immediately deactivates every API key issued under it in this organisation. It does not wait for anything to expire. If you have read an older version of this article saying the opposite, that version was correct at the time and is not correct now.

Three mechanisms, not one lifecycle

A user record carries a status field with eight possible values — STAGED, PROVISIONED, ACTIVE, RECOVERY, PASSWORD_EXPIRED, LOCKED_OUT, SUSPENDED, DEPROVISIONED. It is tempting to read that as a lifecycle you move an account through. It is not. There is no state machine behind those values: no transition table, no rule that says ACTIVE may become SUSPENDED but not the reverse, and no validation of any kind. Users and the directory covers why in practice you will only ever see two of the eight.

What genuinely controls an account is three separate things, and they are independent of each other and of the status label.

The active flag

One boolean. Every authentication path checks it. Turn it off and the next sign-in attempt is refused with user account is inactive and recorded in the audit log as auth.login_inactive. This is the control that matters, and it is fully reversible.

The lockout timer

Five consecutive failed sign-ins lock the account for fifteen minutes. Further attempts are refused with account temporarily locked and recorded as auth.login_locked_out. It clears itself. This is a brute-force defence, not an administrative action, and you should not use it as one.

Deletion

The user row is removed from the database. There is no soft delete, no recycle bin and no undo. See the warning below before you go near it.

Suspending versus deleting

Almost every time, the right answer is to disable the account and leave it in place. The reason is not sentimentality about data — it is that the audit log records actions against a user identifier, and an identifier with no user behind it is a row you cannot explain to an auditor or to yourself.

Two things a disable does not do, and both are worth checking by hand. It does not remove the person from your organisation — their membership row and their role stay, so they will still appear in the user list, correctly, as an inactive member. And the key revocation is scoped to this organisation: if the same person also belongs to another organisation on the platform and holds a key there, that key is untouched and keeps working. Contractors who work with more than one Qorionix customer are the case to watch for.

A sequence that works today

1. 1

   Decide first whether this is a departure or a suspicion

   A resignation with four weeks' notice and a suspected compromised account need the same steps in a different order and at a different speed. For a suspicion, revoke sessions first and ask questions afterwards. For a departure, work down this list on their last day.

2. 2

   Set the account inactive

   Open Identity → Users, find the person, and disable the account. This is the step that does most of the work: the next sign-in is refused with user account is inactive, every session the account holds ends in the same second, and every API key issued under it in this organisation is deactivated. Do not delete at this stage; you almost certainly want the history.

3. 3

   Check the audit entry rather than repeating the work

   Sessions were already ended by the previous step, and the audit trail records it as user.sessions_revoked against your name, with the number affected. Read that line rather than assuming. Revoke sessions is still on the row as a separate action, and pressing it does no harm — it simply has nothing left to do.

4. 4

   Check for keys the person holds under another organisation

   Keys issued under this account in this organisation are already deactivated, and the audit entry says how many. What is not covered is a key the same person holds in a different organisation they also belong to — the effect is deliberately scoped to the one organisation the suspension happened in. If they are a contractor working with several Qorionix customers, that is the loose end. See API tokens.

5. 5

   Decide about group memberships

   Group membership is not removed by disabling an account. If any of your groups are referenced by an access policy, leaving the person in them is a loose end. Remove them from the groups that matter and leave the rest.

6. 6

   If they held admin, read their last month

   Filter the audit log to that user and read the last thirty days. This is not an accusation, it is how you find the undocumented change that breaks something in March. Note that there is no export: you will be reading it on screen or copying it out by hand.

7. 7

   Do the same in Microsoft 365

   Qorionix and Microsoft 365 are separate directories and neither disables the other. Disabling somebody here does nothing to their mailbox. This is the step most likely to be forgotten because the Qorionix side now looks finished.

The deprovision endpoint

There is an endpoint whose job is to do all of the above in one call. It is documented internally as suspend, revoke sessions, revoke API keys, schedule deletion. It requires the strongest user permission there is, and — unlike when this article was last revised — it now works.

It used to fail on its very first step, for everybody, with an HTTP 500 naming an invalid status — the call set a lifecycle value the underlying helper would not accept, and nothing after that line ran. That is fixed. If you searched for invalid status "deprovisioned" and landed here, the answer is that the mismatch has been reconciled and the endpoint now completes: the account is suspended, its sessions are ended, and its API keys in that organisation are deactivated, with the counts reported back to you and written to the audit trail.

So the position today is a working endpoint with one cosmetic edge. Whether you use it or work down the sequence above is now a matter of preference rather than necessity: the sequence is easier to watch happening, the endpoint is one call. Neither of them schedules a deletion, because nothing does.

Lifecycle rules, and what they do not do

The Identity → Lifecycle page lets you define rules of the form when this happens to a user, do that. The rules are stored, listed and edited correctly. The honest description of what they achieve is narrower than the page implies, and it is better to know now than to discover it during an offboarding.

The six events a rule may be triggered by are fixed: user_created, user_updated, group_membership_changed, attribute_changed, manager_changed and user_deactivated. Each execution records a status of pending, succeeded, failed or skipped.

The actions themselves are also uneven. Granting a role is real, and fails with grant_role: missing role if you leave the role name blank. Two of the others do something other than their names: the one called revoke app revokes the user's sessions, and the one called revoke role locks the account rather than removing any role. Assigning an app does nothing at all — it is a placeholder for a provisioning integration that has not landed. The action that would call an AI tool emits a notification that is not connected to anything in the deployed configuration, so it too is inert.

That is four of five actions that either do the wrong thing or nothing. We would rather set out the list than let you discover it one action at a time. Grant a role by changing the person's role directly, and do the rest of the offboarding by hand.

What to do next

1. Users and the directory — what the status field means and why it is not a control.
2. Who can see and do what — the checklist for reviewing who holds admin, which is worth doing whether or not anyone has left.
3. API tokens — the health badges that show you a key whose owner has left, and what an orphaned key does and does not mean.
4. Reactivating a suspended user — if you suspended somebody by mistake and need to bring the account back.