To find group references in Jira permission schemes, review each scheme for permissions granted directly to the group, group custom field values, and role paths that include the group, then record which projects use each scheme before changing anything.
Why this matters
Permission schemes are one of the easiest places to underestimate group risk because they can be shared across multiple projects. A group reference that looks small in a scheme can control Browse Projects, issue actions, or administration across a broad footprint.
Atlassian has a KB workaround for finding group usage in permission schemes via API, which is a useful signal that native review can become manual and fragmented at scale.
For the query jira group permission scheme, the useful answer should help an admin decide what to check now, which rows to hold out, and which proof should survive after the change. That is why this page stays inside a narrow operational boundary instead of becoming a general governance essay.
Working scenario
A Jira admin is asked whether a legacy group can be removed from permissions. The group appears in one scheme, but that scheme is shared by several projects. The admin needs to identify the permission, the projects affected, and the owner who can approve removal.
Inventory The Schemes
Start with all permission schemes, not only the scheme attached to the requesting project. Shared schemes are common, and the same group may appear in several places.
For each match, record the scheme name, permission, grant type, and affected projects.
Check Direct Group Grants
Review permissions granted directly to the group, especially Browse Projects, Administer Projects, issue edit actions, transition actions, and work-item visibility related permissions.
Do not collapse all grants into one risk. Removing a group from Browse Projects has a different impact than removing it from a narrow issue action.
Check Group Custom Field Grants
Jira permission schemes can reference group picker fields. That means the group relationship may appear through data in issues rather than only as a static group name in the scheme.
If a group picker field is used, confirm the field purpose and owner before changing the group model.
Account For Roles In The Scheme
A permission scheme may grant access to a project or space role, and the group may be a member of that role in individual projects. Review the scheme and role membership together.
This is where native screens can split the story: the scheme shows a role, while the role screen shows the group.
Decide Per Permission
For every group reference, decide whether to keep, remove, replace with a role, replace with another group, or hold for owner review.
Preserve a baseline before editing a shared scheme so a reviewer can understand exactly which projects were in scope.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| Group is granted Browse Projects | All projects using the scheme and whether another path grants browse access. | Treat as high risk and require project-owner validation. |
| Group is granted Administer Projects or admin-like permissions | Whether the group still represents trusted project admins. | Replace with a role or narrower owner-approved group before removal. |
| Scheme is shared | Every project attached to the scheme, not only the requesting project. | Coordinate with all affected owners or split the scheme first. |
| Permission is granted to a role | Whether the group is a role member in each relevant project. | Review project role membership before changing the scheme. |
| Group custom field value is used | Which group picker field controls the permission and how values are maintained. | Route to the field owner and document the dependency. |
Common mistakes
Most cleanup errors happen when an admin treats a partial signal as a complete answer. These are the failure modes to watch for on this topic:
- Checking only one project instead of all schemes.
- Forgetting that a permission scheme can be shared.
- Missing role indirection from scheme to project role membership.
- Treating all permissions as the same level of risk.
- Changing a scheme without preserving the before state.
Checklist
- List every permission scheme.
- Find direct group grants and group custom field grants.
- Check which projects use each matching scheme.
- Review project or space roles used by the scheme.
- Classify each reference as keep, replace, remove, or hold.
- Save a scheme baseline before editing.