Permissions, data and limits
What the app can access, what it stores, and troubleshooting.
Permissions the app requests
| Scope | Why it is needed |
|---|---|
read:jira-work, write:jira-work | Read configuration and issues; reassign issues and apply changes. |
read:project:jira, manage:jira-project | Read and manage projects, leads, components and archiving. |
manage:jira-configuration | Read and modify fields, schemes, contexts and filters. This is the core of most tools. |
read:jira-user | Resolve users and groups for the user tools. |
read:board-scope:jira-software, read:board-scope.admin:jira-software | Read boards, so offboarding can report board ownership. |
storage:app | Store job progress, results and tool settings. |
report:personal-data | Report to Atlassian the account IDs held in job results, so a closed account can be erased from them. |
The app declares no external network access at all — there is no allowed-host list in its manifest, because it never calls anything outside the Atlassian APIs it is already running against. The PDF and CSV files are generated in your browser, not by a service.
It is available in nine locales: English (US and UK), Portuguese (Brazil and Portugal), Spanish, French, German, Italian and Japanese.
What the app stores
- Job progress and results for the operations you run: assessments, merger analyses and generated CSV rows, offboarding scans, cleanup scans. Results are kept so you can review a completed run.
- Tool settings, such as the target project and issue type used when a tool creates an issue.
Results contain user names, account IDs and group names when that is what you asked the tool to analyse — a permission audit is a report about people. It is all in the app's own key-value storage inside your Atlassian site; there is no database and nothing leaves.
Closed accounts, and uninstalling
Once a day the app reports the Atlassian account IDs it is holding, so Atlassian can tell it which of those accounts have been closed. When one has been, the records naming that person are deleted. This runs whether or not the app is licensed, because it is a compliance obligation rather than a feature.
Uninstalling runs a handler that empties the app's storage before it goes, sweeping it repeatedly until a pass finds nothing — deleting under a cursor leaves keys behind, so one pass is not enough. Independently, Atlassian detaches the installation's data and destroys it under its own retention policy. See Where your data goes.
preUninstall module now, and it actually deletes.The privacy policy is the authoritative statement on all of the above.
Troubleshooting
- A scan seems stuck
- Large instances genuinely take minutes. If it has actually stalled, use Start Over and re-run with a narrower scope.
- Group changes were rejected
- Expected. Only a site administrator can change group membership. Project roles are still applied, and the tool reports how many group changes were blocked.
- A scheme will not delete
- Something still references it. Re-scan: a scheme that became used between your scan and your delete is reported rather than force-deleted.
- The merger CSV did not import
- Use the generated config file alongside the CSV, import one batch at a time, and make sure the target field is on the relevant screens first.
- User Analysis rejects a CSV
- The tool names the missing columns. Re-export from admin.atlassian.com without opening the file in a spreadsheet first — that round-trip is the usual cause.
- A button is greyed out and I do not know why
- If there is a warning at the top of the page saying the app has no active licence, that is the reason — the actions that start work are gated, and there is a line under each disabled button saying so. Reads, exports and Cancel and start over are not gated.
- Offboarding did not move everything
- Categories marked info only cannot be transferred automatically. They are listed so you can handle them by hand.
Missing a tool? The Suggest a tool button on the tool list and the support portal go to the same queue.