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-user`	Look up users and groups by name, so you can pick the accounts and groups to protect.
`read:jira-work`	Check that the caller holds Jira administration before a resolver acts, and identify which site the app is installed on.
`storage:app`	Store configuration, job state and snapshots.
`report:personal-data`	Report to Atlassian the account IDs held in snapshots and audit records, so a closed account can be erased.

Outbound access is limited to api.atlassian.com: your own site's APIs and, when you connect it, the Atlassian organisation admin API. Nothing goes anywhere else.

What the app stores

Two stores, because the two shapes are different. Everything that grows with the size of your organisation — users, group membership, per-product activity, audit rows — is Forge SQL, one row per thing. Configuration and job state are key-value records.

User snapshots (SQL): Per account: account ID, display name, email address and domain, active flag and account state, account type, managed status, whether Guard bills the account, last-active date, date added to the organisation, product access, licence groups, avatar URL, the sites their access reaches — and, when a CSV import supplied them, two-step verification, verified email, single sign-on, department, job title and organisation-admin role. One further row per account per product, carrying that product's own last-active date.
Groups (SQL): Group IDs, names and kinds, and who belongs to which group in a snapshot.
API tokens (SQL): From a token sweep: the owner's account ID, the token's ID and label, created / last-used / expiry dates. Replaced by the next sweep.
Jobs (SQL): Scan and action jobs: type, status, phase, who requested them — a person, or the schedule — timings, metrics and errors.
Audit log (SQL): Every action with its per-user outcome, kept for 180 days — the entry and its detail on the same horizon.
Rules: Your automation rules and their run state.
Configuration: Inactivity threshold, protected entities, detected licence groups and the organisation ID. The API key is held separately, in Forge's encrypted secret store.

Only the current snapshot and the one before it are kept; older ones are deleted at the end of every scan, along with finished jobs more than 30 days old.

What happens when you uninstall

The app runs an uninstall handler that empties both stores before it goes. It deletes the SQL tables' contents most sensitive first — audit detail and user snapshots before jobs and metadata — so if the handler runs out of its 45-second budget on a very large organisation, what survives longest is configuration rather than names and email addresses. Then it sweeps the key-value store, repeating whole passes until a pass finds nothing, because deleting under a cursor leaves keys behind.

This only became true recently

The handler existed for months wired to a Forge event that does not exist, so it had never run once. It is a preUninstall module now, and it actually deletes. Independently of it, Atlassian detaches the installation's data on uninstall and destroys it under its own retention policy — see Where your data goes.

The privacy policy is the authoritative statement on all of the above.

Troubleshooting

“No user data to browse yet”: Run a scan on the Dashboard. The Users, Automation and Audit tabs all read from a snapshot.
The Scan Users button is greyed out: Either the organisation API is not connected — the Dashboard says so above the button — or the app has no active licence, in which case a warning sits at the top of the page. They are two different problems with two different fixes.
Last-active dates are empty: That data comes from the organisation API. Connect it in Settings.
“Suspend requires Org API connection”: Exactly that: suspension is an organisation-level operation. If you only need the seat back, use Remove from Group instead.
Connection test fails and lists other organisations: The key is valid but the organisation ID does not match. Use one of the IDs in the message, or click Use detected Org ID.
“Another operation is in progress”: One scan or bulk action at a time. Wait for it, or use Force Unlock if a previous run was interrupted.
A rule reports partial: Open the audit entry. The per-user errors name the cause, usually an account managed by another organisation or a group that no longer exists.
Somebody was flagged as inactive but they are working: The snapshot is stale, or their activity is in a product the app cannot see without the organisation API. Re-scan and check the connection before acting.

When you contact support, include the snapshot date and the rule or job in question. Never send the API key.