Practical guide

Hand over moderation as a set of responsibilities, not a password

Last materially reviewed 2026-09-28

Quick answerTransfer the work, permissions and unresolved cases through authorised role changes and a clear acceptance check.
What to know

Describe the actual work

List welcoming, reviewing reported content, answering practical questions, maintaining events and escalating serious issues. Identify which tasks are routine and which require an owner’s decision. A title alone does not tell the incoming volunteer what they are expected to do. Keep sensitive case details in the appropriate restricted system, not in a public onboarding guide.

What to know

Verify the required access

Check the current plan and role permissions for each responsibility. Use individual accounts and legitimate role assignment; do not share the outgoing moderator’s password. Record who can grant and revoke access. A successful role change in a dashboard is configuration evidence, while the incoming person completing the relevant task is separate acceptance evidence.

What to know

Transfer unresolved work explicitly

For each open case, preserve the minimum necessary context, current owner and next decision. Explain deadlines and limitations without promising an outcome the volunteer cannot control. Agree when the outgoing person’s access will be removed or reduced. Do not remove it before essential responsibilities have a verified replacement unless a safety issue requires immediate action.

What to know

A fictional handover

A volunteer leaves before the monthly event. The replacement can moderate discussions but cannot update the event owned by the former host. The group records that gap and establishes an authorised event-management solution. It does not call the handover complete merely because the new volunteer appears on a moderator list. The acceptance check follows the actual responsibilities that would otherwise be left unattended.

What to know

Before you close this task

Ask the incoming moderator to identify the route for a task they are not allowed to perform. Knowing when to escalate is part of readiness. Preserve the handover date, accepted responsibilities and any outstanding gaps so a later volunteer can tell whether a responsibility was deliberately deferred or accidentally left behind.

Continue when useful

Next: Role permissions

Write the task each role needs to perform and verify the permissions that actually support it.

Open Role permissions →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Mighty Networks administration — Merchant documentation · mightynetworks.com · Merchant-controlled · checked 2026-09-28
  2. Mighty Networks pricing — Merchant documentation · mightynetworks.com · Merchant-controlled · checked 2026-09-28
  3. Mighty privacy policy — Merchant documentation · mightynetworks.com · Merchant-controlled · checked 2026-09-28
HANDOVER ACCEPTANCE / ORIGINAL FRAMEWORK

A name on a list is not enough.

ResponsibilityEvidence to checkWhat is not enough
Member helpA reachable route and an accountable helperA help thread inside a locked space
Next eventCorrect time, join route and authorised ownerAn imported event title
Moderator coverThe backup completes the required taskA moderator label alone
Community ownershipThe applicable account process is confirmedA proposed name in a spreadsheet
Build the handover around the work →