How account handover and committee transition work

MapleGather’s account handover moves an outgoing admin’s roles to a successor and archives the outgoing admin’s account, in one guided process. It prevents the access gaps that happen when a volunteer committee member steps down without a formal transition.

The short version

When you step down, you run the handover wizard yourself: choose a successor who is already an active admin and confirm. MapleGather moves the roles assigned directly to you to the successor and archives your admin account in one all-or-nothing step. Then it emails you both. Records you created are not reassigned.

How it works

Starting a handover

Go to Admins (at /admin/admin-security/admins), open a row’s ⋮ menu and select Account handover (or use New handover on the Account Handovers list, at /admin/admin-security/handovers). The handover always covers your own admin account. The wizard has three steps:

1. Choose a successor — pick an existing active admin. (You can also invite a new person, but see the limits below.)
2. Transfer scope — tick events, saved searches, saved reports and integrations. Your choice is saved with the handover, but this version doesn’t reassign records: they stay as they are.
3. Review and complete — check the successor, then confirm.

Once you confirm, the handover runs in the background. You can leave the page; the Handovers list shows how it ended.

Handover statuses

Status	What it means
Awaiting successor	Staged for an invited person who hasn’t accepted yet
In progress	Queued; the transfer is about to run
Complete	Roles moved; the outgoing admin is archived
Failed	A check failed; nothing was transferred, and the banner says why

See Admin handover job statuses reference for full details.

What the transfer does

In one step, MapleGather:

• checks that the successor is an active admin, that the outgoing admin is active (a suspended admin’s handover doesn’t run) and isn’t the successor, and that the handover won’t leave the organization without an Org Owner;
• gives the successor every live role assigned directly to the outgoing admin (a role whose expiry date has passed isn’t moved; for a role the successor already holds, see Edge cases below) and removes the outgoing admin’s roles;
• archives the outgoing admin. Their status becomes handover_complete, they’re signed out, and they can no longer act as an admin.

Then the outgoing admin and the successor each get a confirmation email. It names the roles that moved and any role that wasn’t transferred, with the reason.

Roles that come from a group binding aren’t moved; they stop applying because the archived account can’t act as an admin. Records keep their original owner.

If the job fails

If a check fails, nothing is transferred and the outgoing admin keeps their access. The Handovers list shows “Handover job failed” with the exact cause, for example that the successor’s account is suspended. An unexpected error is retried automatically first. Click Retry to start a new handover with the same successor and choices, or start a new one. See Handover job failed.

Why it works this way

Volunteer organizations regularly face situations where “the previous treasurer left with the only finance account.” A formal handover moves access to the successor and closes the outgoing account in the same step, with an audit trail. Because it is all-or-nothing, there is no moment where the roles have left the outgoing admin but haven’t reached the successor.

Edge cases & boundaries

• Inviting a new person as successor: the handover is staged until they accept their admin invitation. This version doesn’t send that invitation email, and the invitation can’t be accepted yet, so a staged handover doesn’t finish. Hand over to an existing active admin.

• One handover at a time: only one unfinished handover can exist per outgoing admin. Starting another shows “A handover is already active for this admin”.

• A recent sign-in is needed: a handover hands your roles to someone else and closes your account, so starting one (or retrying one) asks you to confirm it’s you if you signed in a while ago — the same check as assigning a role or revoking an admin.

• Suspension stops a pending handover: if the outgoing admin is suspended before the job runs, the handover fails and nothing moves.

• The successor already has a role: for each role assigned directly to you that the successor also holds, the handover keeps whichever of the two assignments covers the other. One assignment covers another when its data scope is the same or wider (no data-scope restriction covers any scope, and more membership levels, tags or event categories cover fewer of the same) and it lasts at least as long (an assignment with no end date outlasts one that has an end date). The successor ends with exactly one of the two assignments as it was, never a mix of them, so nobody ends up with more than either admin had. The successor never loses access they already had.

  • If the successor’s assignment covers yours (including when the two are the same), it’s kept unchanged and nothing moves for that role. The role isn’t listed among the roles that moved.
  • If your assignment covers the successor’s, the successor’s is replaced by an exact copy of yours (same data scope and end date). For example, if you hold Org Owner with no end date and the successor’s Org Owner ends next month, the successor ends with Org Owner and no end date. The audit log records the replacement. An assignment the successor gets through a group binding lasts only as long as the binding, so it never lasts as long as an assignment given directly: if yours has the same or a wider data scope and lasts at least as long, the successor’s is replaced by an exact copy of yours, given directly.
  • If neither covers the other, for example the successor’s assignment is limited to one membership level with no end date and yours to a different level until 1 December, the successor’s is kept unchanged and yours isn’t transferred. The handover’s card on the Handovers list and both confirmation emails list it as not transferred, in one sentence that names the role, says 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 ends one of two ways (shown here for a successor named Jordan Successor and the Finance Manager role). If Jordan Successor’s data scope doesn’t cover yours, or one of the two data scopes can’t be read, it ends “An Org Owner can change Jordan Successor’s existing assignment of Finance Manager (its data scope; its end date can’t be changed in the app yet).” If it already covers yours (the same or wider), it ends “Jordan Successor’s data scope for Finance Manager 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. Giving the successor the role again doesn’t work, because they already hold it: where the successor’s data scope doesn’t cover yours, an Org Owner changes the data scope of the successor’s existing assignment instead, with Configure data scope — see Create a custom role. Changing an assignment’s end date, or removing a single role from an admin, isn’t available in the app yet, so when the successor’s data scope already covers yours, the gap can’t be closed in the app.
  • If the successor’s assignment has passed its end date, or they don’t hold the role, the successor gets an exact copy of yours (same data scope and end date).

  In every case the outgoing admin loses the role, because their account is archived.

Put it into practice

• Run the account handover workflow
• Admin account statuses reference