Deactivate a user in Jira Cloud and nothing gets cleaned up. Their saved filters keep running (and nobody else can edit them), their dashboards keep rendering on wallboards, their issues stay assigned to a dead account, and their projects still list them as lead. Jira has no view that answers the question every admin asks after an offboarding: what did this person leave behind? Deactivated-user reassignment is one of the longest-running admin asks on the Jira issue tracker and Atlassian Community, and offboarding reviews, license reclamation, and access attestations all stall on it.
Why Jira cannot tell you this out of the box
- Deactivation changes nothing on the artifacts. Filters, dashboards, issue assignments, and project leads keep pointing at the deactivated account exactly as before. There is no reassignment step and no prompt.
- There is no reverse lookup. User management shows you that an account is deactivated, but nothing shows you what that account still owns across the site.
- The data is scattered across separate APIs. Filter ownership, dashboard ownership, issue assignees and reporters, and project leads each live behind a different REST endpoint, and nothing in the product joins them against the list of deactivated accounts.
The DIY approach: cross-reference the REST API
Everything you need is reachable through the Jira Cloud REST API. The recipe is to build the list of deactivated accounts first, then sweep each artifact type against it:
- Enumerate deactivated users. Page through
GET /rest/api/3/users/searchand keep accounts withaccountType: atlassianandactive: false, so app, bot, and portal-only customer accounts are never flagged. - Sweep saved filters. Page through
GET /rest/api/3/filter/search?expand=owner&overrideSharePermissions=trueand match each owner against the deactivated list. The override parameter pulls in private filters; some sites reject it for an app identity, in which case you fall back to standard visibility. - Sweep dashboards. Same idea with
GET /rest/api/3/dashboard/search?expand=owner. - Sweep issues. Use
POST /rest/api/3/search/jqlwithassignee in (...)andreporter in (...)clauses, batching the account ids so each query stays under the JQL length limit. - Sweep project leads. Page through
GET /rest/api/3/project/search?expand=leadand flag projects whose lead is deactivated. - Group the hits by departed owner, export to CSV, and hand each ex-employee's pile to whoever inherits it.
The catch is that this is a real script, not a one-liner: five paginated endpoints, JQL batching under length caps, and a result that goes stale the next time someone leaves, so it has to run on a schedule to stay useful.
A ready-made option: Orphaned-Owner Cleanup
Orphaned-Owner Cleanup is that recipe packaged. It scans the whole site daily and on demand, flags every saved filter, dashboard, issue (by assignee and by reporter), and project lead still pointing at a deactivated account, and groups the results by artifact type and by departed owner, largest offender first, so offboarding cleanup becomes a checklist per person. One click exports the full queue as audit-ready CSV, one row per artifact with its type, id, name, project context, and the deactivated account it still points at. The scan and export are read-only; an opt-in bulk-reassign action lets an admin pick an active successor, preview every change (a dry run is the default and writes nothing), then explicitly apply it to issue assignees and saved-filter owners. Dashboards and issue reporters stay manual: the app reports them but never auto-changes them.
Key facts
- Native "what does this deactivated user still own?" view: none in Jira Cloud.
- Deactivation side effects: filters, dashboards, issues, and project leads all keep pointing at the dead account.
- DIY fix: cross-reference five REST endpoints against the deactivated-user list, on a schedule.
- Least privilege: the sweep is read-only (user read plus work read); writes should be opt-in, previewed, and limited to what an admin confirms.
Related reading: set an Entra ID account to expire on a departure date.
Written by the team at Katabarwa Labs. We build small, single-purpose Azure tools that run entirely inside your own tenant. Questions: abaho@llmgraph.ai.