Documentation
Get from install to your first access review. AccessRadar reads Jira permissions, groups and roles and never writes back to them.
Aligned with the AccessRadar product brief and Forge app skeleton on 9 October 2026.
Install and get started
Requirements: Jira Cloud and a Jira site admin to install the app. AccessRadar is a Forge app that appears under Apps → AccessRadar in Jira administration.
- Install. Open AccessRadar on Atlassian Marketplace and choose Try it free, or find it in the Atlassian Marketplace from inside Jira.
- Open AccessRadar from the Apps menu in Jira administration.
- Run the get-started checklist (setup check) so the app can confirm it can read projects, schemes, groups and roles.
- Take or wait for a snapshot, then explore Projects, Groups and People, or open Changes and Reviews.
Where you will find AccessRadar in Jira:
- Admin app with Overview, Explore (Projects, Groups, People), Review (Changes, Reviews, Snapshots) and Settings
- Get started checklist for first-run setup
- Configuration entry that opens Settings
AccessRadar supports Jira's light and dark themes.
Explore access
AccessRadar resolves effective access: who can do what, and through which path (group membership, project role, application role, permission scheme grant).
- Projects — permission schemes (classic and team-managed), roles and actors, browse and admin grants.
- Groups — membership, admin / site-admin / product-user access types where Jira exposes them.
- People — a person's effective access across projects and global permissions the app can read.
This is the view auditors ask for when they ask “who has access to what, and why?” — the gap many teams still fill with spreadsheets, tracked publicly as JRACLOUD-71967.
Snapshots
AccessRadar collects access snapshots on a schedule (and can collect on demand where the UI allows). A snapshot is a point-in-time picture of projects, schemes, roles, groups and resolved effective access stored in Forge SQL.
- Compare two snapshots to see what changed: new grants, removed members, role changes, public or broader access.
- Partial snapshots are labelled when the app could not read everything (for example if an admin restricted the app user). Use the setup check in Settings.
Reviews and sign-off
An access review packages a snapshot (or a diff between snapshots) for human sign-off. When a reviewer completes the review, AccessRadar records a SHA-256 hash of the review package so you can show auditors that the signed content matches what was exported.
Keep the hash with the CSV/PDF export in your evidence folder. Re-hashing the same package later should match the recorded value.
CSV and PDF export
Export reviews and snapshot summaries as CSV (for spreadsheets and GRC tools) or PDF (for evidence packs). Typical uses: SOC 2 access reviews, ISO 27001 access control evidence, and quarterly admin attestations.
Exports are generated inside Forge and downloaded by the signed-in admin. They are not sent to Radrly.
Risk indicators
AccessRadar highlights patterns that usually need a second look:
- Admins — site admins, org admins and project administrators.
- Inactive users with access — accounts that still hold grants or group membership but are inactive in Jira.
- Public grants — permission scheme holders that grant access more broadly than a named group or user (for example anyone / application-role patterns that widen browse).
Indicators are signals for review, not automatic remediations. AccessRadar does not change grants.
Read-only guarantee
AccessRadar requests only granular read:* scopes plus report:personal-data. It has no write or manage scopes. Control checks confirm the app cannot search or edit issues. Snapshots, reviews, hashes and exports live in Forge storage only.
Atlassian may place the app user in admin groups so that read APIs succeed; the scopes still prevent writes. See Security.
Data and residency
AccessRadar stores its data in Atlassian Forge hosted storage (Forge SQL and Key-Value Store). It makes no calls outside Atlassian. The data follows your Jira site's data residency location.
Data stored by the app (typical):
- Atlassian account IDs and display names needed to show people in reviews
- Project keys and IDs, permission scheme IDs, role IDs, group IDs and names
- Resolved effective-access rows and snapshot / review metadata
- SHA-256 hashes and reviewer account IDs for signed reviews
- Export artefacts generated for download
AccessRadar does not store issue content, worklogs, comments or attachments. Email addresses are not stored as a primary identifier.
FAQ
Does AccessRadar change anything in Jira?
No. It only reads permission and directory data. It never creates, updates or deletes issues, users, groups, roles or schemes.
Does my data leave Atlassian?
No. AccessRadar runs on Atlassian (Forge) and makes no calls outside Atlassian. Data is stored in Forge SQL and Key-Value Store and follows your site's data residency.
Why does the app user look like an admin?
Atlassian often adds Forge app users that need directory and scheme reads to admin groups. AccessRadar still has only read scopes, so it cannot perform admin writes. Details are on the Security page.
What is the SHA-256 sign-off for?
It binds the reviewer's approval to a specific review package. Keep the hash with your CSV/PDF export so an auditor can verify the file set has not changed.
Is AccessRadar free?
Free for up to 10 users. Above that, paid per user; final amounts will be published on the overview and Marketplace before general availability.