Removing a member terminates their access to your organisation. They can no longer sign in to the control plane, no longer see any of your tenants, no longer trigger any action. The audit trail of everything they did while they had access is retained. The action is destructive (you can't restore the seat — you'd have to invite them again) but reversible if the removal was a mistake (just re-invite).
When to remove
Section titled “When to remove”Three common shapes:
- Someone left the team. Their access shouldn't outlive their tenure.
- Role change at the wrong tier. They were given Admin but should have been Viewer; demotion is the move, not removal. But if you wanted to remove and re-add at the right role, both are fine paths.
- Security incident. A member's account is suspected compromised; remove first, investigate, re-invite when safe.
Doing the removal
Section titled “Doing the removal”From the Members page, find the member's row. The row action (kebab menu or trailing button) opens a small dropdown that includes Remove member. Clicking it opens a confirm dialog explicitly naming the member you're about to remove.
The dialog requires you to confirm the removal. There's no type-to-confirm friction because removal is reversible by re-inviting — the destructive-action friction tier is reserved for actions that lose data (decommission, hard-delete tenant, delete organisation).
What removal does:
- Terminates the member's session immediately. Their next request returns 401 and routes to the sign-in page.
- Removes the row from the Members tab.
- Emits
org.member_removedto the audit feed with the removed member's id and your id asremoved_by.
What removal doesn't do:
- It doesn't delete the member's user account. They still exist as a user in IntelliAuth; they just don't belong to your organisation anymore. They can be re-invited.
- It doesn't reverse actions they took. Anything they provisioned, suspended, decommissioned, invited, edited — all those actions stay in the audit trail with their attribution.
- It doesn't notify them. No email is sent. If you want to inform them, do so out-of-band.
Who can remove whom
Section titled “Who can remove whom”The constraint matrix:
- Owner can remove anyone except themselves. (Self-removal would leave the org without an Owner.)
- Admin can remove Viewers and other Admins, but not the Owner.
- Viewer can't remove anyone.
- No one can remove themselves. Even Admin can't self-remove. If you want to leave the org, ask another Admin or Owner to remove you.
If you try a constrained action, the UI shows a banner explaining the constraint — for example, an Admin clicking Remove on the Owner's row sees "Owner can only be removed by transferring ownership first."
Re-inviting someone you removed
Section titled “Re-inviting someone you removed”If you remove someone and later want them back, just invite them again with the same email. The platform treats it as a fresh invitation — pending row in the Pending tab, fresh token, fresh 7-day expiry. They click the link, accept, and rejoin with whatever role you assigned in the invite.
What carries over from their previous membership:
- Their user account. They sign in with the same credentials they always had.
- Their email. Invitations are matched by email; the same email reaches the same person.
What doesn't:
- Their previous role. You pick a role when sending the new invite; it doesn't auto-restore.
- Their join date. The Members tab shows them as joined-today, not joined-originally. The audit trail of their previous tenure stays intact for the history.