Reactivating a suspended user
A Reactivate button now sits on any inactive user's row. What pressing it restores, what it cannot bring back, and who is allowed to press it.
You suspended somebody by accident, or a colleague did, and you want the account back. There is a Reactivate button for exactly this, on the person's row in Identity → Users, and it works on its own — no proposal, no workaround, no support call. What it will not do is put back everything the suspension took away, and that is the part of this article worth reading.
Where the button is
Open Identity → Users and find the person. An inactive account carries a Reactivate button on its row, alongside the other row actions. Press it, confirm, and the account is active again with the role and group memberships it always had.
One row will not show it: somebody who was invited and never completed their invitation. They are not a suspended user — they have no usable account yet — so there is nothing to reactivate. Invite them again instead; see What an invited user actually receives.
What reactivating does, and does not, undo
- Sign-in ability
- Restored immediately. The account can authenticate again on its next attempt, with the password it already had.
- Group memberships, role and assignments
- Untouched by either suspending or reactivating. Nothing is removed when you suspend and nothing needs restoring when you reactivate — the account picks up exactly where it left off.
- Sessions
- Not restored, and they were not left running either. Suspending ended every session the account held, in the same second, everywhere. Reactivating does not recreate them — the person simply signs in again, on each device they use.
- API keys
- Not restored. Every key issued under the account in this organisation was deactivated by the suspension and stays deactivated. A replacement key has to be created and the integration pointed at it. A key the same person holds under a different organisation was never touched and is still working.
- MFA enrolment
- Kept. A reactivated user is not asked to re-enrol a second factor unless it was separately reset.
The same change, asked for in a sentence
You do not have to use the button. Changing a user's status — suspending, locking or reactivating — is one of the five kinds of change the Sentinel-Q change-proposals feature can draft today: sign-in rules, network zones, account status, group membership and role assignment. Go to Sentinel-Q → Change proposals and type the request in a sentence: reactivate the account for [email protected].
Sentinel-Q drafts the change, shows the account's current status and who is affected, and waits for your approval before anything happens. It is worth the extra step when you want the blast-radius reading before you act — it flags whether the account you are reactivating is an administrator, and whether the change affects you — and worth skipping when you know exactly which one row you meant to press.
Who can do it
Pressing Reactivate needs users:write. Going the Sentinel-Q route needs the permission to talk to Sentinel-Q for the draft, the higher decide permission to approve it, and — because approving a change is not a way around a permission you do not hold — users:write as well. See Roles and permissions for which built-in roles carry it.
What to do next
- Reactivate the account from Identity → Users, then tell the person they will have to sign in again on every device.
- Work out whether anything was authenticating as that account — a script, an integration, a scheduled job — and issue a replacement key for it. See API tokens.
- If the suspension was somebody else's action and you are not sure why it happened, read the audit entry before reversing it. It records who suspended the account, when, and how many sessions and keys were affected.