Skip to main content
When someone leaves the organization, removal is one call, but the work around it is a sequence: see what the leaver owns, decide what happens to each asset, remove the member, and prove the revocation landed. This runbook walks that sequence in order. The day-to-day mechanics of the Settings → Team console (the Remove control, the role matrix, pending invites) live in Team members, invitations, and roles; this page is the operational wrapper around that one action. Every control in this runbook is tenant-owned: the inventory, the decisions, and the removal all happen inside your organization. Nothing here touches how calls or messages are delivered.

​
1. Pre-removal inventory

Before anyone presses Remove, walk the surfaces below and note what the leaver holds. Ten minutes here prevents the two classic offboarding failures: an integration that dies at midnight because it ran on the leaver’s API key, and an inbox queue that quietly fills because open threads kept an assignee who can no longer answer. For directory-synced members, also note whether the person is still assigned to the Orbit application in your identity provider. That decides which removal path you use in Section 3.

​
2. Decide: hand over, reassign first, or discard

Each asset class falls into one of three buckets. The removal call itself transfers the leaver’s per-user assets to an owner; everything else is your decision, made before the removal. The buckets map to a simple rule: if the platform transfers it (per-user assets), verify afterwards; if a customer expects an answer tomorrow (conversations, routing), reassign now; if only the leaver used it (keys, stale reports), discard.

​
3. Remove the member

There are two removal paths, and the right one is decided by how the member was provisioned.

​
Manual removal (owner-only)

For members invited through Settings → Team. Open Settings → Team, find the row, and press Remove, or call the endpoint directly:
Two guards shape this call:
  • Owner only. Admins can invite, resend, revoke invitations, and change roles, but the server refuses a removal from anyone but the owner. The Remove control only renders for owners for the same reason.
  • You cannot remove yourself. The last owner can never strand the organization by deleting their own seat.
Ownership itself never travels through this call. Transferring the owner role is a separate, support-mediated flow, so a departing owner is handled before any removal, not by one. One call performs the full revocation: the member’s active sessions are torn down, their API keys are revoked, their per-user assets are handed over to an owner, and the complete revocation summary is written to the audit log. The seat frees immediately (seat quota guide).

​
SCIM deprovision (directory-synced members)

For members provisioned by your identity provider, remove them in the IdP instead: unassign the person from the Orbit application (or send the DELETE), and the sync performs the same revocation cascade on the Orbit side, including the asset transfer to an owner. active: false is the softer step: it deactivates the account and blocks sign-in while the row stays, which is the right move mid-process if you might reactivate. Deprovision is the terminal one. See SCIM provisioning for the Okta, Entra ID, and OneLogin walkthroughs.
Do not manually remove a member who is still assigned to the Orbit application in your IdP. The next sync cycle sees the assignment and provisions the person again, undoing your removal. For directory-synced members, the IdP is the source of truth; remove them there.

​
4. Post-removal verification

Confirm the revocation on four surfaces, each of which reads a different part of the cascade:
  1. Audit log. Open Settings → Audit log (or the export) and find the removal entry. The revocation summary on that row lists what was torn down and revoked, and who received the leaver’s per-user assets. This is the row an auditor will ask for; see the audit log guide for filtering and export.
  2. Session management. Open Settings → Security and check the active-sessions surface: no session for the leaver remains. The session review workflow is in the org security guide.
  3. API keys. In Settings → API keys, the leaver’s keys show as revoked, not merely unused.
  4. Team roster. Back on Settings → Team, the row is gone and the pending-plus-live seat count has dropped by one.
For a SCIM deprovision, add the sync side: the Settings → SCIM activity panel (and the health read) shows the deprovision applied, so you can tell a clean cascade from a push the IdP still owes you.

​
5. Planned departure vs immediate removal

With notice. Run Sections 1 and 2 during the notice period, with the leaver present where possible: they know which integration holds their key and which reports anyone reads. Reassign conversations and rosters, mint replacement keys, and perform the removal on the last day. The removal then has nothing left to surprise you. Immediate (security) removal. Remove first, inventory second. The removal call is the containment: sessions end and keys die with it, so the access risk closes in one action. Afterwards, work the inventory from the audit history instead of the live consoles, and add the org-level steps that do not depend on the leaver’s account state:
  • Deny support access if a window is open. Support access is granted to your organization, not to a member, so it survives any single removal; denying closes the window and ends active support sessions in one action.
  • Revoke all other sessions from the security console if you suspect the leaver’s credentials were shared or cached on a device you do not control.
  • Review the require-2FA posture for the roles the leaver held, so the next sign-in attempt anywhere needs a factor the leaver does not have.
The org security guide walks each of these controls and the audit rows they write. In both modes, remember that removal ends access but not history: the leaver’s audit-log entries remain, which is exactly what an investigation or handover review needs.

​
6. Re-hire path

A removed member can always come back, and how their history behaves depends on the path:
  • Manual removal. Re-invite the address from Settings → Team whenever you like, subject to the usual seat quota. The new membership starts fresh with the role you assign; the person’s earlier audit-log entries remain in your ledger, so their history as a member of the organization is still readable.
  • SCIM deactivation (active: false). Reactivating in the IdP restores the same account with its history, because the row never left.
  • SCIM deprovision (DELETE). A later push provisions a fresh account for the email. The old account’s audit history persists in your organization’s log either way.
What does not come back on any path is access: keys stay revoked, sessions stay torn down, and roles, skill tags, and roster memberships must be re-established like any new member’s.