> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Member offboarding and leaver runbook

> Run a complete leaver offboarding: inventory what the departing member owns, decide per asset whether it is handed over, reassigned, or discarded, remove the member (owner-only removal or SCIM deprovision), and verify the revocation end to end.

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](https://docs.orbit.devotel.io/guides/organization-team-management.md); 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.

| Asset | Where to look | What to note |
| - | - | - |
| API keys | **Settings → API keys** ([guide](https://docs.orbit.devotel.io/guides/api-keys-end-to-end.md)) | Every key the leaver created, and which integration or script presents it. |
| Live conversations and pending replies | **Inbox**, filtered by assignee; the pending-replies view ([guide](https://docs.orbit.devotel.io/guides/inbox-pending-replies.md)) | Open threads, drafts, and replies waiting on the leaver. |
| Scheduled reports | The scheduled reports console ([guide](https://docs.orbit.devotel.io/guides/scheduled-reports.md)) | Reports the leaver configured, and who reads them. |
| Flows and AI agents | The flows and agents consoles | Anything personally owned by the leaver rather than by a teammate who stays. |
| Voicemail boxes | **Voice → Voicemail** ([personal boxes](https://docs.orbit.devotel.io/guides/voice-voicemail-boxes.md), [team inbox](https://docs.orbit.devotel.io/guides/voice-team-voicemail-inbox.md)) | Personal boxes holding live greetings, and any team box the leaver maintains. |
| Routing skills and team memberships | **Settings → Team** skill tags and **Voice → Teams** rosters ([skills](https://docs.orbit.devotel.io/guides/voice-skill-certifications.md), [teams](https://docs.orbit.devotel.io/guides/teams.md)) | Skill certifications and queue rosters that route work to the leaver. |

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.

| Asset | Bucket | Your action before removal |
| - | - | - |
| Flows, AI agents, and other per-user assets | Hand over | None required. The removal call transfers them to an owner and names the recipient in the revocation summary. If a specific teammate should own them afterwards, plan that follow-up in the owning console. |
| Live conversations and pending replies | Reassign first | Assign each open thread to a teammate who stays, so replies keep going out. Unattended threads do not fail loudly; they just age. |
| Queue and routing-team membership | Reassign first | Remove the leaver from **Voice → Teams** rosters so routing stops offering them work. |
| Skill certifications | Reassign first | Grant the covering teammates the same skill tags before the leaver's tags disappear with the removal. |
| API keys | Discard | The removal revokes them; there is no transfer. Any integration that still needs access gets a fresh key created by a member who stays, minted **before** the removal so nothing lapses. |
| Voicemail boxes | Decide | Personal boxes ride along in the per-user handover. Move any greeting or box a team still needs into a [team voicemail inbox](https://docs.orbit.devotel.io/guides/voice-team-voicemail-inbox.md) first. |
| Scheduled reports | Decide | Re-point reports that keep their audience, delete the rest. A report nobody reclaims keeps mailing a departed address book. |

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:

```bash theme={null}
curl -X DELETE "https://api.orbit.devotel.io/api/v1/settings/team/{userId}" \
  -H "Authorization: Bearer $ORBIT_API_KEY"
```

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](https://docs.orbit.devotel.io/guides/team-seat-quota-operations.md)).

### 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](https://docs.orbit.devotel.io/guides/scim-provisioning.md) for the Okta, Entra ID, and OneLogin walkthroughs.

> [!WARNING]
>
> 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](https://docs.orbit.devotel.io/guides/audit-log.md) 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](https://docs.orbit.devotel.io/guides/org-security-posture-operations.md).
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](https://docs.orbit.devotel.io/guides/org-security-posture-operations.md) 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](https://docs.orbit.devotel.io/guides/team-seat-quota-operations.md). 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.

## Related guides

* [Team members, invitations, and roles](https://docs.orbit.devotel.io/guides/organization-team-management.md) — the Settings → Team console this runbook operates.
* [SCIM provisioning](https://docs.orbit.devotel.io/guides/scim-provisioning.md) — directory-driven provisioning and deprovisioning for Okta, Entra ID, and OneLogin.
* [Team seat quotas](https://docs.orbit.devotel.io/guides/team-seat-quota-operations.md) — how removal frees a seat and unblocks invites.
* [Org security posture operations](https://docs.orbit.devotel.io/guides/org-security-posture-operations.md) — session revocation, support access, and 2FA enforcement for the security-leaver path.
* [Audit log](https://docs.orbit.devotel.io/guides/audit-log.md) — the complete, exportable record the verification step reads.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.