Administrator guide

What Handover does · Running an offboarding · The audit report · Manual steps · Groups · Settings · Permissions · Troubleshooting · Data & privacy · Support

What Handover does

When a person leaves your organization, deactivating their Atlassian account changes nothing about what they own. Handover inventories what a departing user still holds in Jira and transfers it to successors you choose, in one audited run:

Category	What happens
Open issues assigned to them	Reassigned to a successor (optionally with an explanatory comment)
Saved filters they own, including private filters	Ownership transferred
Dashboards they own	Ownership transferred and verified (see below)
Components where they are lead	Lead changed
Projects where they are lead	Lead changed
Group memberships	Snapshotted into the audit, then re-grantable per group as the clicking admin

Closed and Done issues are deliberately untouched: reassigning finished work would rewrite history. Scans cover up to 5,000 open issues per run and say so in the wizard when capped.

Running an offboarding

Choose person: search by name. Active or deactivated accounts both work.
Review inventory: a read-only scan shows totals per category. Nothing is modified at this step, ever.
Assign successors: pick one default successor; optionally override per project (issues and component leads) or per category. The leaver can never be chosen as a successor, and successors are verified as active before the plan is created.
Confirm: a summary of every transfer that will run, including any guided steps you could be left with if Jira blocks an automatic path.
Execute: transfers run in background batches with live progress. You can leave the page; the run continues and is always visible under History → In progress. When finished, the audit report opens.

The audit report

Every run is recorded: who ran it, when, every item, its successor and its outcome (done, manual, or failed with Jira's error). Export any run as CSV; the export opens with a header naming the plan, the person, who executed it, and start and finish times. The file is assembled on Atlassian's Forge infrastructure from data stored in your own Jira and downloaded straight to your browser; it never touches an external service. Admins can permanently delete any record from its report page.

How dashboard transfers work

Handover transfers dashboard ownership through Atlassian's bulk change-owner API. Because Atlassian marks that endpoint Experimental, Handover never takes its answer on faith: after every reported success it reads the dashboard back and records in the audit whether the new owner was verified directly. When the automatic path is blocked (most commonly the Share dashboards and filters global permission, Atlassian bug JRACLOUD-96603), the row becomes a guided step instead of a silent failure: press Retry as me to run the same change under your own permissions, or follow the exact instructions (Jira Settings → System → Shared dashboards → Change owner) and press Mark done. Every path lands in the audit.

Scope limit worth knowing: no Jira API can list a dashboard the leaver never shared with anyone. Site admins can review those on the same Shared dashboards admin page. Private filters are fully included in scans.

How group transfers work

Atlassian's architecture does not let any app change group membership on its own authority; group writes only succeed with the permissions of a real organization admin. Handover treats that as a feature. The leaver's memberships are snapshotted into the audit, and from the report an org admin can re-grant them per group: pick a successor, approve each add or remove, and the change runs as you at the moment you click. Handover never stores admin credentials and cannot touch groups in the background. Directory-managed groups (SCIM, Okta, Microsoft Entra) are detected and flagged for your IdP instead of silently reverting on the next sync, privileged groups require a typed confirmation, and Atlassian-managed groups are refused outright.

Settings

Comment on reassigned issues by default pre-checks the wizard option. Comment template supports {leaver} and {successor} placeholders, replaced with display names.

Permissions (scopes) and why

Scope	Used for
`read:jira-user`	Finding the leaver and successors
`read:jira-work`	Scanning issues, filters, dashboards
`write:jira-work`	Reassigning issues, adding comments, transferring filters and dashboards
`manage:jira-project`	Changing project and component leads
`manage:jira-configuration`	Admin-level reads, including private-filter visibility
`read:dashboard:jira`, `write:dashboard:jira`, `read:group:jira`, `write:group:jira`	Granular equivalents declared up front so future Atlassian API changes never force a permission re-approval
`storage:app`	Storing plans, progress and audit history in Forge storage

All scopes are declared up front so an update never surprises you with a permission re-approval. Every backend operation additionally re-verifies that the invoking user is a Jira administrator.

Troubleshooting

A few items show failed: the run does not stop for individual failures. The note column carries Jira's error (most commonly the successor lacks Assignable User permission in that project). Fix the permission and run a new handover for the same person; already-transferred items will not reappear in a fresh scan.
Scan shows 0 issues but I can see some: the scan targets open issues (status category not Done) assigned to the person. Reported-by is not ownership and is out of scope for transfers.
Progress seems stuck: very large plans process in batches; progress persists and reloading is safe. A run whose progress has genuinely stalled shows a Resume button in its report under History.
The person has thousands of issues: scans cover the first 5,000 open issues per run and the wizard says so when capped. Run Handover again after the first run to pick up the remainder.
JSM projects: assigning service-desk issues requires the successor to hold a JSM agent license; without one those items record as failed with Jira's error. Pick an agent as the successor for JSM projects.
Archived projects: Jira's APIs return live projects; leads of archived projects are not part of the scan.

Data & privacy

Handover runs entirely on Atlassian's Forge platform: no external servers, no data egress, data residency follows your site automatically. It stores plans (including issue keys and one-line summaries), progress and audit summaries in Forge storage. Delete any record from its report page. Before uninstalling, export the audit CSVs you need; uninstalling removes the app's storage under Atlassian's Forge data lifecycle. See the Privacy Policy.

Support

[email protected]. We respond within one business day. Include the plan ID from the audit report for fastest help.