Admin handover job statuses reference

This page lists every status the AdminHandover.status field can hold and what each means for the predecessor (outgoing) and successor accounts.

Job statuses

Status	Badge on the Handovers list	Meaning	Predecessor account status
`pending_successor_invite`	Awaiting successor	Staged on the invite path. Nothing is transferred until the invitee accepts their admin invitation. The current version sends no invitation email and can’t accept the invitation, so this status doesn’t progress.	`active` — unchanged.
`in_progress`	In progress	Queued with an existing successor; the transfer job is about to run or running.	`active` — unchanged until the job completes.
`complete`	Complete	The roles assigned directly to the predecessor moved to the successor, except a role the successor already held with an assignment that covers the predecessor’s (kept, nothing moved) and any listed on the card as not transferred (see Roles moved below). The predecessor was archived. Both parties were emailed a confirmation naming the roles that moved and any that weren’t transferred, with the reason. Records were not reassigned. Terminal.	`handover_complete` — archived; signed out; can’t act as an admin.
`failed`	Failed	A check failed or the job hit an internal error on every attempt. The banner names the exact cause. Nothing was transferred. Terminal.	Unchanged — the predecessor keeps their access.

Behavior notes

Topic	Detail
One step	The transfer runs as a single all-or-nothing step: it moves every role and archives the predecessor, or changes nothing.
Roles moved	Only live roles assigned directly to the predecessor; a direct role whose expiry date has passed isn’t moved. Roles from a group binding aren’t moved. Where the successor already holds the role, the assignment that covers the other is kept. One assignment covers another when its data scope is the same or wider (no restriction covers any scope; more membership levels, tags or event categories cover fewer of the same) and it lasts at least as long (no end date outlasts any end date). If the successor’s covers the predecessor’s (including when they are the same), it’s kept unchanged and nothing moves for that role; the role isn’t listed as moved. If the predecessor’s covers the successor’s, the successor’s is replaced by an exact copy of the predecessor’s (same data scope and end date), and the audit log records the replacement. A successor’s assignment from a group binding lasts only as long as the binding, so it never lasts at least as long as a direct assignment: where the predecessor’s has the same or a wider data scope and lasts at least as long, it is replaced by an exact copy given directly. If neither covers the other, the successor’s is kept unchanged and the predecessor’s isn’t transferred: the Complete card and both confirmation emails list it as not transferred, in one sentence naming the role and which part of each assignment the other doesn’t cover (how many membership levels, tags or event categories one includes and the other doesn’t — the number, not their names — and which one ends earlier) and ending, where the successor’s data scope doesn’t cover the predecessor’s or one of the two data scopes can’t be read, “An Org Owner can change [successor]’s existing assignment of [role] (its data scope; its end date can’t be changed in the app yet).”, or, where it already covers the predecessor’s (the same or wider), “[successor]’s data scope for [role] already covers the outgoing admin’s, and the app cannot change the rest yet: an assignment’s end date can’t be changed and a role assignment can’t be removed in the app.”; the audit log records the role and the reason code. If the successor’s assignment has passed its end date, or they don’t hold the role, the predecessor’s assignment is given exactly. The successor never loses access they already had, and ends with exactly one of the two assignments, never a mix.
Suspended predecessor	A handover whose predecessor is suspended when the job runs doesn’t run: it is marked `failed` with “The outgoing admin’s account is suspended, so the handover did not run. Nothing was transferred and the outgoing admin’s account is unchanged.”
Records	Events, saved searches, saved reports and integrations are not reassigned. The wizard’s Step 2 choice is saved with the handover only.
Status updates	The Handovers list shows the status when the page loads. Reload it to see a change.
Confirmation email	Sent to both the predecessor and the successor after a handover completes. It names the roles that moved and any role that wasn’t transferred, with the reason.
Internal errors	An unexpected error is retried automatically. After the last attempt the handover is marked `failed` with “The handover stopped on an internal error after N attempts. Nothing was transferred and the outgoing admin’s account is unchanged.” The same happens when the job stops and can’t be run again, so a handover is never left In progress for good.
On failure	The banner on the Handovers list shows the cause verbatim. Retry (shown to the outgoing admin only, on their own failed handover) starts a new handover with the same predecessor, successor and choices. It shows when the failed handover named a successor and nothing newer exists for that predecessor.
One at a time	Only one handover that isn’t finished can exist per predecessor. Starting another returns “A handover is already active for this admin”.
Terminal state	`complete` and `failed` are terminal. An archived predecessor can’t be reactivated.