Before you delete a Jira group, do you know every place it is actually used?

[#1]

Delete a Jira group and something breaks quietly three weeks later: notifications stop, a filter's audience empties, a team loses board access. Before you remove one you need every place it grants access, and Jira has no screen that shows you.

The question lands during a security review, an offboarding, or a permission-scheme cleanup. It is one of the most-voted gaps in the product: JRACLOUD-71967 ("Group usage - List of project permission per group") has over 1,000 votes and is still open.

Atlassian ships a support-KB Python script for it, but it reads permission schemes only. Groups also grant access through project roles, notification schemes, and filter shares, so the script returns scheme names, not the real answer, and someone has to keep maintaining it.

Disclosure: I work for Katabarwa Labs, and we build a small app for exactly this, so treat it as one option among whatever you evaluate.

Access Governance Reporter crawls permission schemes and project roles in one pass and answers the group question both ways. Per group: every project and permission it grants, and whether that comes from a scheme or a role. Per user: the full effective-access view, with the exact group or role behind each grant. The report is summary-first, exports to audit-ready CSV in one click, and includes an opt-in, preview-first cleanup that removes deactivated users from groups and roles (dry run first, never automatic). It runs entirely on Atlassian Forge inside your tenant, so nothing leaves your instance, and the report path is read-only.

Listing, if it helps: Access Governance Reporter. If your access review needs a surface we do not cover yet, tell us and we will build it.

[Alan Bruce]

Very nice. I find it hard to believe that this is not an out of the box option that 'should' be available already for security audit purposes.