Permissions and Scopes
Audit 360 for Jira requests the following Jira API scopes. All access is read-only — the app never writes to your Jira instance.
Scopes
| Scope | Why it's needed |
|---|---|
read:jira-work | Reads field definitions, project configurations, filter metadata, and dashboard metadata. Issues are accessed only as counts via JQL — no issue content is read or stored. |
read:jira-user | Captures the account ID of the user who triggered each audit run for run attribution. Display names are not stored. |
read:board-scope:jira-software | Reads board metadata and identifies which boards are backed by a given filter. Used by the Filter Audit to establish filter usage. |
read:board-scope.admin:jira-software | Enumerates all filters site-wide, including private and restricted ones. Without this, the Filter Audit misses filters not explicitly shared with the app. |
manage:jira-configuration | Reads screens, screen schemes, field configurations, and workflows — the admin-layer data that shows which fields are actually referenced. These endpoints require admin access even for read operations. |
manage:jira-project | Reads project feature flags and ensures complete project visibility regardless of permission schemes. No project settings are modified. |
storage:app | Forge SQL stores audit results, field review decisions, and run history. Forge KVS tracks active job state and is cleared when each job completes. Both are scoped to your installation. |
For details on what is stored, what is excluded, and how long data is retained, see Data Handling and Security.