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.

[SPHIOR]

Solo dev to solo dev — this is a good build, and JRACLOUD-71967 sitting at ~1,000 votes since 2019 with no plans for another year or two is exactly the kind of gap worth filling.

You asked what surfaces you might be missing. Four that aren't on your uncovered list and are easy to forget:

JSM approvers configured as a group. Approval steps can point at a group rather than named users, and removing the group silently breaks the approval step rather than erroring.

JSM organizations and portal access. Group-to-organization mappings decide who can see a portal at all, which is usually the scariest one to get wrong.

Filter subscriptions. You cover filters, but subscriptions are a separate object with their own recipient — often a group — and a subscription pointed at a deleted group just quietly stops emailing anyone.

Project role default members. The global defaults that seed new projects are a different table from per-project role actors, so a group can be absent from every existing project and still land in the next one somebody creates.

On your second question, about access review workflows — one thing worth being upfront about with buyers, because it caught me out: a scan answers "where is this group used right now", but an access review usually asks "who had this access during Q2, and was that appropriate". Those are different questions. A point-in-time scan can't reconstruct last quarter, so whatever the tool is, it only starts being useful for review purposes from the day it's first run. Auditors are fine with that as long as you say it plainly. They are much less fine with discovering it themselves.

Disclosure so it's not weird: I also build a Jira app, in the change-history end of the same problem rather than the group end. Not pitching at you — you asked for missing surfaces and I had four.

[Fabian Hönes]

Thanks, that is exactly the kind of list I was hoping for.

Two of the four are in the scan already. Filter subscriptions are checked separately from the share permissions, so a subscription whose recipient is the group shows up even if the filter itself is not shared with it. And the global default role actors are checked separately from the per-project actors, for the reason you give: a group can be in no project today and still land in the next one.

The two JSM ones are real gaps. Approval steps that point at a group, and group-to-organization mappings for portal access, are not scanned today, and the "not covered" list in the report does not mention them either, which it should. I will add both to that list in the next release and check whether the JSM APIs expose them in a way a read-only Forge app can query.

The point about snapshot vs. period is well taken. The report is a picture of right now, it cannot reconstruct last quarter. The listing says that, but not as plainly as you just did, so I will fix the wording.