AccessLens for Jira — documentation
Where to find it
After installing, open Jira → Settings → Apps → AccessLens. The app has a single admin page with four tabs: Explore, Snapshots, Reviews and Settings. Jira restricts this page to site administrators.
Start with a snapshot
Every answer AccessLens gives comes from a snapshot, so take one first: Snapshots → Take snapshot now.
This is not a workaround. Answering “which projects can this group reach?” requires reading every project's permission scheme anyway, and a point-in-time answer is the one an audit can use — “who had access on 30 September” is a question live data cannot answer at all.
A scan reads every project's permission scheme and roles, then expands group membership. Large sites are split into shards that run in parallel, with a progress bar showing projects scanned, shards complete and an estimate. A scan that runs long re-queues itself and resumes where it left off rather than starting over.
Only one scan runs at a time. If a scan is already in progress, Take
snapshot now is disabled until it finishes or you cancel it. Cancelling keeps whatever was
already collected and marks the snapshot cancelled, so partial data can never
be mistaken for a complete picture.
Answer “who can access what”
The Explore tab offers three directions, all against a chosen snapshot:
- By group — every project the group can reach, and with what
- By user — including access inherited through group membership
- By project — everyone who can reach it, flattened
Access held through project roles and group membership is expanded for you, so what you see is effective access rather than what the scheme literally says. Each result carries a provenance line naming the snapshot and when it was taken.
Compare two quarters
Snapshots → Compare two snapshots. Pick any two and you get one row per real change, not a stream of events.
Order does not matter — AccessLens compares by capture time, so selecting them the wrong way round will not invert “granted” and “revoked”. A subject that was only renamed is reported as a rename rather than as one subject losing access and another gaining it.
Run an access review
- Reviews → Start a review, choose a completed snapshot and give it a title.
- Walk the project list. For each one, Confirm the access or flag it for Remediate, with an optional note. Projects with risk findings sort first.
- Sign off once nothing is pending. Sign-off is refused while any project is undecided, so a signed record cannot claim a completeness it does not have.
- Export sign-off record for the evidence pack.
Every decision records the reviewer's Atlassian account id and a server-side UTC timestamp. Both come from the Forge invocation context rather than the browser, so attribution cannot be forged. Changing a decision keeps the previous one, and superseded decisions appear in the exported record — a reversal is visible rather than silently overwritten.
Signing off is permanent. The review freezes: no decision or note can be changed afterwards, by anyone. That is what makes the exported record hold up, and it is why there is no way to reopen it. Export before you sign if you are unsure.
Schedule scans
Settings → set the cadence to weekly or monthly and pick the day. Scheduled scans run in UTC. A scheduled run that collides with a manual one is skipped rather than queued, so two scans never race.
Retention
Snapshots are kept until you delete them, up to a limit you set (default 12). At the limit, AccessLens refuses a new snapshot rather than deleting an old one. Audit evidence is never discarded automatically — export and delete a snapshot yourself to make room.
When AccessLens cannot see everything
Some sites do not permit reading group members. When that happens the capability probe
detects it and the snapshot is marked groups not expanded. Group-level answers
stay complete; per-user answers cover only permissions granted to that user directly, and
the app says so in the UI and in every export rather than quietly under-reporting.
Separately, a project whose permission scheme could not be read is recorded as partial and marked in results and exports, rather than being dropped from the snapshot.
Exports
Lookups, snapshots, diffs and sign-off records all export to CSV. Files are generated in your browser as UTF-8 with a byte-order mark and CRLF line endings, so non-ASCII project names survive a round trip through Excel. Every export carries a provenance header naming the snapshot, the scan window, and any degraded capability.
A full-site scan is not transactional. Permissions changed during the scan window may be captured inconsistently, and the export header says so — an auditor should know the window, not just the timestamp.
Permissions the app requests
| Scope | What it is for |
|---|---|
read:jira-work | Enumerate projects; read project roles and permission schemes |
read:jira-user | Resolve user display names |
manage:jira-configuration | Read group members. The app writes no configuration and issues no write requests at all; this is the only path to group membership, and without it “which projects can this person reach” is unanswerable. |
storage:app | Store snapshots and reviews in Atlassian-hosted app storage |
There is no external permission, so Forge blocks outbound calls at the platform
level. See the privacy policy for what is stored and where.
Support
Questions, bug reports and feature requests: github.com/keelapps/support.
Security issues: report privately, not in a public issue.
Privacy or data requests: use the address on the privacy policy.