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	Guided manual step with a Mark done control (see below)
Components where they are lead	Lead changed
Projects where they are lead	Lead changed
Group memberships	Snapshot only: recorded in the audit, never edited

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 manual steps you will be left with.
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.

Why dashboards are a manual step

Jira Cloud's only endpoint for changing a dashboard's owner is marked Experimental, so Handover does not build your compliance record on it. Instead it lists each affected dashboard with exact instructions (Jira Settings → System → Shared dashboards → Change owner), gives the row a Mark done button, and records the step and who completed it 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.

Why groups are snapshot-only

Group membership is frequently directory-managed (SCIM, Okta, Microsoft Entra). An app-side removal would silently revert on the next sync or conflict with your identity source of truth. Handover records the leaver's memberships in the audit so your identity team can act with full information in the system that owns it.

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
`manage:jira-project`	Changing project and component leads
`manage:jira-configuration`	Admin-level reads, including private-filter visibility
`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

support@greylineinteractive.com. We respond within one business day. Include the plan ID from the audit report for fastest help.