Offboarding
What removing someone from an organization revokes, what it deliberately leaves alone, and what happens if you re-add them
Overview
Removing someone from an organization revokes their access in that organization. Three things are deactivated:
- Their role assignments
- Their group memberships
- Their per-person allow overrides
Access stops at the next decision. There is no cache to wait for.
On an older deployment, removing someone from an organization left their role assignments, group memberships and overrides active, and the project access path re-admitted them. Verify this behaviour on your own deployment before you rely on member removal as your only offboarding step.
What is kept, and why
Three deliberate exceptions. Each one looks like an omission and is not.
Offboarding sets the assignment inactive rather than removing the row, so the record of who held what, and when survives.
A delete would destroy exactly the evidence an incident review needs. If you are asked six months later what a departed person could reach, the answer still exists.
Revocation removes grants, not restrictions. A per-person deny survives offboarding.
This is the safe direction. Deactivating a deny would quietly widen access for anyone who came back, which is the opposite of what offboarding is for.
An assignment that is not scoped to an organization is not that organization's to revoke.
One organization offboarding a person must not strip a grant another organization, or the platform itself, made.
Re-adding someone
Re-adding a person to the organization re-creates only the Default role floor. It does not restore the roles, group memberships or overrides they had before.
| Scenario | Result |
|---|---|
| You removed someone by accident, then re-added them | They hold the Default role. Their previous bespoke access is not restored. |
| You removed someone deliberately, then re-added them later | Same. You grant what they need now, deliberately. |
| They had a per-person deny before | The deny is still active. |
This is the right default, even though it means extra work after an accidental removal.
An administrator who "removed" someone expects their access to be gone. Silently restoring bespoke grants on re-add would break that expectation, and restoring them should be a deliberate act.
Offboarding checklist
Member removal handles MagOneAI access. It does not handle everything a person may have left behind.
Remove the person from the organization
This revokes roles, group memberships and allow overrides, in this organization.
Check their platform-scoped assignments
If they held anything not scoped to your organization, a platform administrator has to remove it. Your removal deliberately left it alone.
Rotate credentials they could read
Access control stops them reading a secret from now on. It does not change a secret they already read.
Rotate any API key, provider credential or secret they had access to. See Secrets management.
Reassign what they owned
Check for schedules, inbound webhooks, outbound webhook subscriptions and knowledge bases that named them, and anything pointing at a personal credential of theirs. A tool connection authorized with their account stops working when their account does.
Confirm with effective permissions
Open Effective permissions for the person and confirm it is empty apart from anything you intended to leave. This is the authoritative check.
Troubleshooting
Causes to check, in order:
- They hold a platform-scoped assignment, which your removal left alone on purpose. A platform administrator must remove it.
- Another organization still has them as a member.
- The access comes from a credential they already hold, not from a permission. Rotate it.
Cause: Working as designed. Re-adding restores only the Default role.
Fix: Assign the roles they need now, or add them back to the groups they belonged to.
Cause: A per-person deny from before is still active, because denies survive offboarding.
Fix: Remove the deny if it was situational. Keep it if it was a standing restriction.
Cause: Rows are deactivated rather than deleted, so the history survives.
This is intended. An inactive assignment grants nothing.