Suspend (disable) a user when you need to stop them signing in but keep their record. Reversible.
How to suspend
Section titled “How to suspend”User detail page → Actions menu → Disable user. State chip flips from active to disabled. Save is immediate; no confirmation modal (it's reversible).
What happens:
- All active sessions are revoked. The user is signed out everywhere within seconds.
- New sign-in attempts return
account_disabled. - Refresh-token attempts fail.
- API calls with the user's access tokens fail on the next token introspection (or as the access token expires, whichever comes first).
Re-enable
Section titled “Re-enable”User detail page → state chip → flip back to active. Or Actions menu → Enable user. Same place; no separate undo button.
The user can sign in again with their existing password / MFA factors. No re-enrolment.
When to suspend
Section titled “When to suspend”- Offboarding — an employee leaves; suspend their account on day-zero; consider deleting after retention.
- Investigation — a user is suspected of doing something suspicious; suspend pending investigation.
- Compliance hold — legal asks you to freeze the account.
- Temporary lockout — repeated brute-force from a user's IP; suspend the user pending password reset + investigation.
Suspend vs delete
Section titled “Suspend vs delete”| Reversible? | Record preserved? | Audit trail intact? | |
|---|---|---|---|
| Suspend | Yes | Yes | Yes |
| Delete | No | No | Yes (the audit log persists per retention policy) |
Default to suspend. Delete is for "I'm certain this user record should be erased" — see Delete a user.
user.disabled lands in audit with you as the actor, plus optional reason text. Use the reason field — six months from now you'll want to know why.
user.enabled records the re-enable.
The user list supports multi-select + bulk disable / enable. Useful when offboarding a team — filter by group, multi-select, disable.