Why this question matters more than it sounds
"Where is this group used?" is not a curiosity question. It is a pre-change control question.
If you answer it badly, several different kinds of failure show up:
- a permission path disappears in a shared scheme
- a project role keeps depending on the group even though the name looked obsolete
- a rename fails because the old group name is still embedded in JQL
- the team postpones cleanup because no one wants to approve a guess
This is also why "nobody remembers using it" is weak evidence. Jira groups often outlive the reason they were created. The name ages faster than the usage. A stale-looking group can still be part of active access plumbing.
If you need the broad model behind that, start with Jira Permissions Explained or How Jira Groups Actually Work. This page is narrower: how to locate usage before you touch the group.
Start with the surfaces that change access immediately
Not every usage surface has the same cleanup importance.
If your goal is safe rename or deletion, start with the surfaces most likely to change live access:
| Surface | Why it matters first | What to confirm |
|---|---|---|
| Default-group status | A default access group can still place users into the product automatically. | Is this group a default access group or tied to one? |
| Permission schemes | One reference can affect many projects at once. | Does the group still grant a real permission path? |
| Project roles | A role can hide why the group still matters operationally. | Which projects still rely on the mapping? |
| Saved filters and JQL | A rename may fail even when access impact looks small. | Is the group name used in membersOf() or similar clauses? |
| Group ownership and sync status | The real control point may be outside Jira. | Is the group internally managed, legacy, or externally synced? |
Atlassian's user-management and Jira administration docs are clear on two points that matter here:
- default groups are special because they help grant product access automatically
- permission schemes and project roles are still core places where groups affect Jira access
Those two facts explain why the cleanup review should start with access-bearing surfaces, not just with general group browsing.
A cloud-first preflight workflow
The safest way to answer "where is this group used?" is to move from the most consequential surfaces to the more scattered ones.
1. Check whether the group is part of product-access logic
In Atlassian Administration, confirm whether the group is a default group or otherwise tied to app access. Atlassian's documentation on default groups makes the risk explicit: users are automatically placed into default groups when access is granted, and that can lead to unintended license consumption if the setup is not carefully maintained.
If the group is a default access group, stop treating this like a simple cleanup rename. You are now dealing with an access-path decision.
2. Review permission-scheme references
Next, look for permission-scheme usage. This is where one old group can still matter across many projects. Atlassian even documents a Cloud knowledge-base route for finding group usage in permission schemes via REST API and Python. That is a useful signal by itself: teams often need something more exact than manual clicking.
The practical question is not "does the group appear anywhere?" It is "does the group still grant a live permission that makes deletion or rename unsafe today?"
3. Review project-role usage
Groups also show up indirectly through project roles. That matters because project owners may not think in terms of group names; they think in terms of who can administer, browse, or work in the project.
This is where cleanup often gets political by accident. The platform team sees an old group. The project owner sees a working role assignment. That mismatch is why it helps to record both the technical reference and the operational effect.
4. Check whether rename is blocked by filters or other settings
Atlassian's Jira Cloud knowledge-base article on the "unable to edit group name" error shows a real edge case admins hit in practice: renaming a group can fail because the old group name is still referenced in saved filters' JQL, for example through membersOf("Developers").
That is a useful reminder that rename is not always the low-risk option it sounds like. If a group name is embedded in filters or other settings, you may need to update those references first.
5. Check sync/ownership boundaries
If the group is externally managed, SCIM-synced, or owned outside the Jira admin team, the technical answer alone is not enough. You need to know who is allowed to change it and whether the correct fix belongs in Jira, Atlassian Administration, or the identity provider.
That is another reason to write the findings down cleanly. The next step may belong to a different owner entirely.
What people usually miss
The name is not the dependency
The name is just the clue that starts the investigation.
A group called old-contractors-emea may still grant live access in one shared scheme. A group called jira-users-temp may be harmless. The cleanup decision should never be made from naming alone.
Rename and delete do not have the same preflight
Delete asks whether the group is still needed at all.
Rename asks whether the old name is referenced in places that will block or confuse the change.
Those are related questions, but not identical ones. If your team keeps treating rename as the soft version of delete, read Jira Rename Group vs Delete Group next.
One screenshot is not proof of usage review
A screenshot proves that one screen existed at one moment. It does not prove which surfaces were checked, what the scope was, or whether the next reviewer can trust the result later.
That is the hidden cost in native admin work. The first admin may be careful. The second reviewer still receives a weak artifact.
Default-group status changes the whole risk profile
If the group is part of default product access, the question is no longer just "where is it used in Jira?" The question becomes "what automatic access path are we about to disturb?"
That deserves a different level of caution.
A practical "usage map" checklist
Before you approve any rename or deletion, record at least this:
- The exact group name reviewed
- Whether the group is internally managed or externally synced
- Whether the group is a default access group or tied to product access
- Permission-scheme references found
- Project-role references found
- Filter or JQL references that could block rename
- The likely action: rename, delete, replace, or hold
- The owner for any follow-up outside the Jira admin team
That list is deliberately small. The point is not to create bureaucracy. The point is to make the answer portable enough that the next reviewer does not need to reconstruct it from memory.
Example: a group that looks old but is not safe yet
Imagine a group called legacy-oncall-emea.
At first glance, it looks like a naming artifact from an old team structure. The Jira admin assumes the likely options are rename or delete. The preflight shows a different story:
- it is not a default access group
- it still appears in one shared permission scheme
- it is still mapped into a project role for two service projects
- the old name appears in one saved filter used by a team lead
That is no longer a cosmetic cleanup. It is a small access-remediation plan.
The likely next move is not "delete now." It is:
- replace the permission-scheme reference
- update the project-role mapping
- clean up the filter reference
- then decide whether rename or deletion is still the right final action
The value of the preflight is that it turns vague fear into sequence. You know what still depends on the group, who needs to be involved, and which action should happen first.
When native Jira is enough and when it stops being enough
Native Jira and Atlassian Administration are enough when:
- the group question is small
- one admin is doing a bounded spot check
- nobody needs a durable review artifact afterward
They start to fragment when:
- the group still matters in multiple surfaces
- another reviewer needs to approve the change
- the team wants a baseline for later cleanup
- screenshots and notes are turning into the proof model
That is the point where the problem stops being "can I technically check this?" and becomes "can I package this review cleanly enough that another person can trust it?"
Where Group Impact Audit for Jira fits
This is where Group Impact Audit for Jira earns its place.
The product is not trying to replace Atlassian Administration or act like a full identity platform. Its value is narrower and more useful for this job: read-only pre-change review of where a Jira group still matters across supported Jira surfaces, with evidence that survives handoff.
If you are already past the broad diagnostic stage, the most useful next step is usually one of these:
- compare native Jira vs Group Impact Audit
- use the Jira group cleanup use case
- read the action-stage checklist on what to review before deleting or renaming a Jira group
FAQ
Can Jira show everywhere a group is used from one screen?
Not cleanly. Some usage is visible in admin screens, but the answer is often fragmented across Atlassian Administration, Jira admin settings, project-role assignments, and filter/JQL references.
What usually matters most before deleting a group?
Default-group status, permission-scheme references, and project-role mappings usually matter most because they are closest to live access impact.
Why can a rename fail even if deletion looked possible?
Because the old group name may still be referenced in filters or settings. Atlassian documents rename failures caused by saved filters that still use the group name in JQL.
When does a focused app become worth it?
When the burden is no longer just finding one reference. It becomes worth it when the team needs a repeatable, read-only review and evidence another person can trust later without rebuilding the search.