Where is this group used in Jira Cloud? Every place to check before you delete a group
Why this keeps coming up
Jira Cloud shows you where a project role is used, but not where a group is used. JRACLOUD-71967 has asked for that since 2019 and has about a thousand votes; Atlassian's last update (November 2024) said it would not be built in the following 12–18 months, and that window has passed. Atlassian's own Delete a group page says only: "Before you delete a group, check if the group is used to configure permissions in any of your apps" — and gives no way to do that check.
So before you delete or empty a group, you are on your own, and the damage from a wrong guess is quiet: people stop receiving notifications, a filter or dashboard that was shared only with that group disappears for everyone else, issues behind a security level become invisible, a workflow transition starts failing its condition, or new users stop getting product access because the group was a default group. None of that throws an error.
Where a group can be used in Jira Cloud
Inside Jira, a group can sit in any of these places:
- Permission schemes (as a permission holder), which reach every project using the scheme
- Project roles — as a role actor per project, and as a default actor that gets added to every future project
- Notification schemes (as a recipient)
- Issue security levels
- Filters — shared with the group, editable by the group, referenced in JQL via
membersOf("group"), or with a subscription that mails the group - Dashboards — shared with or editable by the group
- Product access — application-role groups and the default group for new users (this lives in admin.atlassian.com, not in Jira settings)
- Global permissions (Jira settings → System → Global permissions)
- Workflow conditions and validators ("user is in group"), including conditions provided by apps such as ScriptRunner or JSU
- Automation rule conditions
- Board administrators, comment and worklog visibility restrictions, group-picker custom fields on issues
And outside Jira: Confluence space permissions and page restrictions, and other products in the same organization. A group that looks unused in Jira can still be load-bearing elsewhere.
What the UI gives you
Object by object, yes; per group, no. You can open each permission scheme, each notification scheme, each project's role page and look for the group. For a handful of projects that is fine. For fifty, it is not, and filters and dashboards are not browsable that way at all.
One trick a commenter on the ticket describes, and which works for roles and permissions: create a test account, put it in the group you want to audit and in no other group, then open that user in User management and view its Jira project roles. Everything it shows came through the group. It does not show filters, dashboards, notifications or subscriptions.
What the REST API gives you
If you script it, these are the calls (Jira Cloud REST API v3, run as a Jira admin with an
API token). Everything is paginated (startAt / maxResults), and a
large site will take hundreds to thousands of requests — one commenter on the ticket reports
2,000+ requests and ten minutes for about 1,500 groups — so expect HTTP 429 and add backoff.
| Place | Call | What to look for |
|---|---|---|
| Permission schemes | GET /rest/api/3/permissionscheme?expand=permissions, then GET /rest/api/3/project/{key}/permissionscheme per project | permissions[].holder.type == "group"; holder.parameter is the group name, holder.value the group ID |
| Project roles | GET /rest/api/3/role, then GET /rest/api/3/project/{id}/role/{roleId} per project; default actors: GET /rest/api/3/role/{id}/actors | actors with type atlassian-group-role-actor |
| Notification schemes | GET /rest/api/3/notificationscheme?expand=all; projects per scheme: GET /rest/api/3/notificationscheme/project?notificationSchemeId=… | recipients with notificationType == "Group" |
| Issue security | GET /rest/api/3/issuesecurityschemes, then GET /rest/api/3/issuesecurityschemes/level/member?schemeId=…&expand=group | returns members for company-managed schemes only; team-managed projects do not expose their security members here |
| Filters | GET /rest/api/3/filter/search?expand=sharePermissions,editPermissions,owner,jql,subscriptions&overrideSharePermissions=true | overrideSharePermissions is the important bit: without it you only see filters shared with you. Check sharePermissions[] and editPermissions[] for type group, search jql for membersOf, and look at subscriptions[]. Subscriptions created by other users may still not be visible to you. |
| Dashboards | GET /rest/api/3/dashboard/search?groupId=…&expand=sharePermissions,editPermissions | no admin override here; you only see dashboards visible to your account. If you are not in the group, you will miss dashboards shared only with it. |
| Product access | GET /rest/api/3/applicationrole | groups and defaultGroups per application role |
| Members | GET /rest/api/3/group/member?groupId=…&includeInactiveUsers=true | how many people, and how many deactivated accounts, a change affects |
| Workflow conditions | GET /rest/api/3/workflows/search?expand=values.transitions (the older /workflow/search?expand=transitions.rules is deprecated) | each transition carries its conditions as rules with a ruleKey and parameters; group conditions carry the group in the parameters. App-provided conditions (ScriptRunner, JSU) have their own rule keys and formats. |
| Automation | no API that searches rules by group | what works in bulk: Jira settings → System → Automation rules → … → Export rules, one JSON file with all global and project rules; search it for the group name |
| Global permissions | no public API that returns the grantees | the Global permissions page in Jira settings is the only place to check, by hand |
A minimal example for the filter call, which is the one most scripts forget:
curl -s -u you@example.com:API_TOKEN \
"https://your-site.atlassian.net/rest/api/3/filter/search?expand=sharePermissions,editPermissions,jql,subscriptions&overrideSharePermissions=true&maxResults=100&startAt=0"Before you delete a group, a short checklist
- Export the member list first (you cannot undo a deletion, and membership is the one thing you can restore by hand).
- Check whether the group is a default group for product access; if it is, new users will stop getting the product.
- Look for filters and dashboards shared only with this group — their owners will not be warned.
- Look at notification schemes; lost notifications are the failure nobody notices for weeks.
- Look at issue security levels; issues do not disappear, they become invisible.
- Open Global permissions by hand.
- Search the workflow conditions and the automation export for the group name.
- If your organization also uses Confluence, check space permissions and page restrictions there; a deleted group can leave a restriction that only Atlassian support can remove.
- Keep what you found, with a date, as the evidence for your next access review.
Where an app fits, and where it does not
I built Group Audit for Jira because I got tired of the script. It is a read-only admin page that runs items 1–7 of the list above for one group and exports the result as CSV with a completeness status per row; it does not cover 8–11 or anything outside Jira, and every report says so. If you are happy with your script, keep it — the calls above are exactly what it runs. If you want to try it, it is on the Atlassian Marketplace, free for sites up to 10 users.
If you have a cleaner way to get global permission grantees or automation conditions than the ones above, write to kontakt@arbeitstyp.de; I will update the article.