Atlassian's own script for finding group usage in Jira, and what it misses

Ask any Jira admin who has tried to delete a group: before you remove it, you need to know every place it is used, or something breaks quietly three weeks later. The feature request for a native group-usage view has been open on the Jira issue tracker for years and has collected over a thousand votes. Atlassian's answer, for now, lives in a support KB article: a Python script you run yourself against the REST API. The same article tells you the script is beyond Atlassian Support's scope, and that permission schemes are not the only place groups are used. Both statements are worth taking seriously.

What the KB script actually does

• Calls GET /rest/api/3/permissionscheme?expand=permissions to pull every permission scheme and its grants.
• Loops through the grants looking for your target group name.
• Prints the names of the schemes that reference the group.

That is a useful start, and for a one-off check on a small site it may be all you need. But the output is a list of scheme names, not answers. It does not tell you which projects use those schemes, which permissions the group actually holds there, or who is in the group and therefore inherits all of it.

Where groups hide beyond permission schemes

The KB's own caveat is the important part. A group can also sit in any of these, and the script sees none of them:

• Project roles, per project, plus the default role actors applied to every new project.
• Notification schemes, so deleting the group silently stops emails.
• Issue security levels, so members lose visibility of restricted issues.
• Filter sharing and edit grants, membersOf() clauses inside filter JQL, and filter subscriptions.
• Dashboard sharing.
• Product access (application roles), which is how the group may be granting Jira seats.
• Group-picker custom fields, workflow conditions and validators, automation rules, and board permissions.
• Global permissions, where Jira Cloud has no public API that returns the grantees at all.

Extending the DIY approach

If you want to stay in script land, the honest version of the job looks like this:

• Start from the KB script's scheme scan, then resolve schemes to projects with GET /rest/api/3/project/{id}/permissionscheme so you know where each grant actually applies.
• Walk GET /rest/api/3/project/{id}/role and each role's actors to catch role-based grants, which the scheme scan misses entirely.
• Add per-surface passes for notification schemes, issue security schemes, filters, and dashboards, each with its own pagination and its own edge cases.
• Keep a completeness note per surface, because some (global permissions above all) cannot be enumerated via the public API, and an audit that silently omits them is worse than one that says so.

One admin on the feature-request thread reported his home-grown version of this makes roughly two thousand REST requests per run. It works, until the person who wrote it leaves, or an API changes, or the security review asks where the script runs and what token it uses.

A ready-made option: Access Governance Reporter

Access Governance Reporter is the productized version of the pattern above, in both directions. It crawls permission schemes with their grants, resolves them to the projects that use them, and walks every project role and its actors. From that it answers the group question the KB script starts on: for any group, every project and permission it grants, and whether the grant comes from a scheme or a role. It also answers the reverse question the script cannot: for any user, the full effective-access view, every project and permission with the exact group or role that grants it. A summary-first dashboard loads instantly at any site size, everything is searchable server-side, and one click exports audit-ready CSV for access reviews.

Key facts

• The native gap: Jira Cloud has no built-in view of where a group is used; the thousand-vote feature request remains open.
• Atlassian's DIY answer: an unsupported Python script covering permission schemes only, with the KB itself noting groups also live in global permissions, filter shares, dashboards, and more.
• The durable fix: a crawl that resolves schemes to projects and includes role actors, with honest completeness notes for surfaces the API cannot enumerate.
• Least privilege: the read path needs only read scopes; nothing in Jira is modified by reporting.

Related reading: Jira's audit log has the same DIY-script answer for retention: here is how to keep records past the window.

Written by the team at Katabarwa Labs. We build small, single-purpose Azure tools that run entirely inside your own tenant. Questions: abaho@llmgraph.ai.