Deletion is irreversible. The user record, every linked identity, every MFA factor, every session — gone from the live data. The audit log keeps a record of the deletion (with the actor + timestamp + reason) per the tenant's retention policy, but PII inside audit log entries is also redacted in deletion.
This is the surface for GDPR Article 17 ("right to erasure") requests and any other workflow where "the user record must be erased" is the goal.
How to delete
Section titled “How to delete”User detail page → Actions menu → Delete user.
A confirmation modal asks you to:
- Type
deleteto confirm. - Optionally enter a reason — visible in audit afterwards.
- Optionally select GDPR mode — see below.
Click confirm. The deletion is queued (it can take a few seconds; large user records with many sessions take longer).
Normal delete vs GDPR mode
Section titled “Normal delete vs GDPR mode”| Normal delete | GDPR mode | |
|---|---|---|
| User record | Removed | Removed |
| Linked identities (Google, GitHub, SAML) | Removed | Removed |
| MFA factors | Removed | Removed |
| Sessions | Revoked + removed | Revoked + removed |
| Audit log entries referencing this user | Retained with user_id | Retained, PII redacted (email + name replaced with [redacted]; user_id retained as a stable hash) |
| Downstream webhook subscribers | Receive user.deleted event | Receive user.deleted event with PII fields redacted |
Use GDPR mode when the deletion is in response to a data-subject erasure request. Use Normal when the deletion is for routine cleanup (a disabled account aged out; a duplicate record).
Cascading effects
Section titled “Cascading effects”When a user is deleted:
- The
user.deletedwebhook fires, letting integrators clean up downstream systems. - Group memberships that referenced this user are removed (the groups themselves persist).
- Resource ownerships (in the ReBAC surface) involving this user are removed.
- The user's email is freed — a new user could sign up with the same email later. The deleted user's records are NOT inherited by the new account.
What's NOT auto-cascaded
Section titled “What's NOT auto-cascaded”- Records in your downstream systems (your CRM, your DB, your analytics pipeline). The
user.deletedwebhook is your notification; your code is responsible for the downstream cleanup. - Audit log entries about the user's actions — they remain (PII-redacted in GDPR mode) because audit is the compliance record of what happened. The user_id remains as a stable hash so audit can still link "this action happened by this person" historically even after the email is gone.
The retention timeline
Section titled “The retention timeline”- Immediately on delete: user record gone, sessions revoked, MFA factors purged.
- Within 30 days: any backup-eligible copies of the user record are also purged. Backup retention is per-tenant policy.
- Audit log entries: retained per tenant policy (default 365 days; the PII inside them is redacted on GDPR-mode delete).
For full erasure including audit, the tenant's audit retention policy must roll off — set the policy short enough that the GDPR-redacted entries age out within the regulatory window.
Confirm the user is really erased
Section titled “Confirm the user is really erased”After deletion, you can verify:
- The user no longer appears in Users list (any state filter, any time range).
- The
user.deletedevent is in the audit log with your actor id. - If you subscribed to webhooks for
user.deleted, the event arrived at your receiver. - If you query the management API for the user_id, the response is 404.
What to tell a GDPR-requesting user
Section titled “What to tell a GDPR-requesting user”A typical legal response after completing erasure:
Your data has been erased from our authentication platform as requested. The action took effect on <timestamp>; sessions across all devices have been ended. Any references to your account in operational audit logs have been anonymised. Backup copies will be erased within 30 days. Your data has also been propagated to our downstream systems via our standard event channel.
The audit log entry for the deletion is your evidence if the user asks for proof later.
Common mistakes
Section titled “Common mistakes”- Deleting when the user just wants to change email. Edit the email instead; don't delete + create.
- Forgetting the downstream. Your CRM still has the user's name + email + history. The webhook fires; your code has to act.
- GDPR mode for routine cleanup. Wastes the PII-redaction operation. Use Normal for cleanup; reserve GDPR mode for actual data-subject requests so the audit trail correctly reflects intent.