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 native feature request for a group-usage view has over a thousand votes and remains open. Atlassian's current answer is a support KB article with a Python script you run yourself, and the article itself tells you two important things: the script is beyond Atlassian Support's scope, and permission schemes are not the only place groups are used.
What the KB script does
- Calls
GET /rest/api/3/permissionscheme?expand=permissionsfor every scheme and its grants - Loops the grants looking for your group name
- Prints the scheme names that reference it
Useful for a one-off check. But the output is scheme names, not answers: it does not tell you which projects use those schemes, which permissions the group holds there, or who inherits all of it through membership.
Where groups hide beyond permission schemes
The KB's own caveat is the important part. A group can also sit in:
- Project roles, per project, plus the default role actors for new projects
- Notification schemes (delete the group, silently stop emails)
- Issue security levels
-
Filter sharing and edit grants,
membersOf()in filter JQL, filter subscriptions - Dashboard sharing
- Product access (application roles), which may be granting Jira seats
- Group-picker custom fields, workflow conditions and validators, automation rules, board permissions
- Global permissions, where Jira Cloud has no public API that returns grantees at all
One admin on the feature-request thread reported his home-grown crawler makes roughly two thousand REST requests per run. It works, until the author leaves or the security review asks where that script runs and what token it holds.
Extending the DIY version honestly
- Resolve schemes to projects with
GET /rest/api/3/project/{id}/permissionschemeso grants map to where they apply - Walk
GET /rest/api/3/project/{id}/roleand each role's actors; the scheme scan misses role grants entirely - Add per-surface passes (notification schemes, issue security, filters, dashboards), each with its own pagination
- Record a completeness note per surface, because some (global permissions above all) cannot be enumerated, and an audit that silently omits them is worse than one that says so
The packaged version
We productized this pattern as Access Governance Reporter (disclosure: I am the author). It crawls schemes with grants, resolves them to projects, and walks every role and its actors, then answers both directions: per group, every project and permission it grants and whether it comes from a scheme or a role; per user, the full effective-access view with the exact group or role behind each grant. Summary-first dashboard that loads instantly at any site size, server-side search, one-click audit-ready CSV. It is a Forge app: everything runs on Atlassian's platform inside your tenant, and nothing leaves your instance. Free for up to 10 users.
If your access-review workflow needs a surface we do not cover yet, tell us and we will build it.
