When someone leaves, the identity provider sends SCIM either an update that sets active to false or a DELETE. Neither guarantees that the person's sessions, API tokens and shared data are gone. Test what each app really does, then add the steps SCIM does not cover.
What the standards say
RFC 7643 defines active as a Boolean administrative status whose exact meaning the service provider decides. Typically true means the user can log in and false means the account is suspended. That wording leaves room for apps to do very different things.
RFC 7644 says a DELETE succeeds with 204, and that a provider may choose not to permanently delete the resource, but must return 404 for later operations on it and omit it from queries. So a soft delete is allowed.
Deactivate or delete
Deactivate (active false) | Delete | |
|---|---|---|
| Reversible | Yes, usually | Often not |
| Keeps history and ownership | Yes | App specific |
| Frees the license | App specific | Usually |
| Typical use | Leavers, leave of absence | Data removal, cleanup |
Many teams deactivate first, keep the account for a retention period for ownership transfer, then delete.
What SCIM does not guarantee
- Existing sessions. An active browser session may live on until its own expiry.
- API keys and personal tokens. These may belong to the user and keep working.
- OAuth grants the user gave to third party apps.
- Shared resources such as documents, channels and repos the user owned.
- Local accounts or break glass logins that bypass SSO.
Offboarding checklist
- Disable the user in the identity provider first.
- Confirm SCIM pushed the change, and read the provisioning log for errors.
- In each app, verify the user cannot sign in, and that sessions are ended.
- Revoke the user's API keys, personal access tokens and OAuth grants.
- Transfer ownership of resources, groups and automations.
- Remove from any local or non SSO accounts.
- Delete after your retention period, if the app allows.
- Keep evidence: the date and time of disable, who approved it, and a screenshot or export showing access removed.
Test it before you need it
Create a test user, give them a session, an API token and some owned content, then deactivate through SCIM. Record what still works. Do this for each important app and write the results into your offboarding runbook.
Watch for failure modes
- SCIM token expired, so changes silently stopped.
- Provisioning scoped to a group that the leaver was moved out of before the sync.
- App only supports user creation, not deactivation, on a lower plan.
- Rate limits causing a backlog during mass departures.
Alert when provisioning fails, and review a sample of leavers each quarter.
Quick check
Is setting active to false the same as deleting?
No. It suspends the account, usually reversibly. Deletion removes the resource, though providers may keep data internally.
Does deactivation revoke API tokens?
Not necessarily. The standard leaves behavior to the service provider, so test and revoke tokens explicitly.
Sources
Last reviewed: 19 October 2026.
