Permissions and Scopes
Audit 360 for Jira needs read-oriented Jira permissions so it can inventory configuration and usage signals for administrators. The app also uses Forge-hosted storage for summarized audit results and run history.
Why Permissions Are Needed
| Permission area | Why Audit 360 needs it |
|---|---|
| Jira work read access | Read issue and configuration metadata needed for count-only usage checks and field analysis. |
| Jira user read access | Show run attribution where Jira exposes profile details at view time. Durable results store stable account identifiers, not profile payloads. |
| Jira Software board read access | Identify board dependencies where Jira exposes board and filter relationships. |
| Jira configuration read access | Read field, workflow, screen, and project configuration signals used by audits. |
| Forge app storage | Store non-sensitive configuration, job progress, summarized results, run history, pinned metadata, and soft-delete state. |
Read-Only Audit Workflows
Audit workflows are read-only. Audit 360 does not call Jira write APIs to modify fields, screens, workflows, filters, boards, dashboards, projects, work items, or Automation rules.
Scope Changes
If your administrator is asked to approve changed permissions after an app update, review the release notes and installation prompt before approving the update.