Jira Cloud: a read-only "where is this group used" audit (JRACLOUD-71967) — what does it miss?

[Fabian Hönes]

Disclosure: I am the developer of the app below. It is a Marketplace Partner app, and I am one person, not a company.

If you have ever had to change or delete a Jira group, you know the feeling: you cannot see where it is used. JRACLOUD-71967 has asked for this since 2019, has about a thousand votes, and Atlassian said in November 2024 that it would not be built in the following 12–18 months; that window has passed. The workaround in the ticket is a REST script that covers permission schemes only. Admins on the ticket describe the rest: scripts with more than 2,000 API requests per sweep, a test account they add to the group to see its roles, or a support ticket before every cleanup.

I built a Forge app that turns that into one admin page: Group Audit for Jira.

How it works: Jira settings → Apps → Group Audit. Type a group name, click Scan. A checklist shows each area being scanned; large sites are scanned in resumable chunks with rate-limit backoff, so hundreds of projects or thousands of filters just take longer. You get a summary ("N usages in M places · affects P projects"), a result table with deep links, and a CSV export.

What it scans today (Jira Cloud, read-only):

• Permission schemes — the group as a permission holder, attributed to the projects that use the scheme
• Notification schemes — the group as recipient (group-custom-field events are flagged "manual check required" rather than guessed)
• Project roles — the group as role actor in every project, plus default role actors for future projects
• Issue security schemes — the group as a security-level member
• Filters — sharing and edit grants (all filters, via admin override), JQL that references the group via membersOf(), and subscriptions that mail the group
• Dashboards — sharing and edit grants, as visible to your account
• Product access — application-role access groups, incl. the default-for-new-users flag
• Group members — total, active and deactivated counts, so you know how many people a change affects

What it does not scan, and says so in every report, in the UI and in the CSV: workflow conditions and validators, automation rule conditions, board and sprint permissions, comment and worklog visibility restrictions, values of group-picker custom fields, archived projects, global permission grantees (Jira Cloud exposes no API that returns them), issue security of team-managed projects, and anything outside Jira — a group used in Confluence is a separate problem. Dashboards and subscriptions are only visible in the scanning admin's context; if you are not a member of the audited group, the report tells you that coverage is partial. Lens Group Debugger, which is also on the Marketplace, lists workflows and custom fields in its coverage; mine does not yet, so compare both.

The CSV is built for access reviews (ISO 27001, SOC 2, SOX UARs): every row carries the group, the scan timestamp, the site and a scan status. If any check could not finish — rate limits on a big site, a transient Jira error — the report is marked INCOMPLETE in the banner, in the status column and in the filename. A report that silently omits things is worse than no report, so it never does that.

Permissions and data: all scopes are granular read scopes, deliberately not "Administer Jira". The app cannot change or delete anything. No storage, no egress, no analytics; it runs entirely on Atlassian infrastructure ("Runs on Atlassian"), so nothing leaves your site. The scope list with a justification per scope is linked from the listing.

Marketplace listing: https://marketplace.atlassian.com/apps/1133367000

Two things I would genuinely like to know from people who run larger sites:

1. Which of the uncovered surfaces hurts most in practice — workflow conditions, automation rules, or Confluence? That decides what I build next.
2. How do you run group access reviews today — scripts, support tickets, a spreadsheet? If the CSV is missing a column your auditor asks for, tell me which.

And if the app misses a place where your group is used, please say so here — that is the feedback that matters most. I would still rather see this native in Jira; until then, keep voting on JRACLOUD-71967.