To find group references in Jira project roles, check which roles contain the group in each project, then check where those roles are used in permission schemes, notification schemes, workflow conditions, security levels, and other configuration before changing membership.
Why this matters
Project or space roles are useful because they let a shared scheme stay flexible, but they also hide group impact behind a role name. A permission scheme may show Developers or Administrators while the risky group reference lives in role membership.
The admin needs both sides of the story: where the group is assigned to a role and where that role grants real capability.
For the query jira group project roles, 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 group is not visible in the permission scheme, so a cleanup owner assumes it is unused. A deeper review shows the group is a member of a role used by the scheme. The cleanup decision changes from delete to owner review.
List Role Membership By Project
Review each project or space where the group may be assigned to a role. Record the role name, project, and whether the role membership is inherited from a template or maintained locally.
A group assigned to Administrators, Developers, Service Desk Team, or a custom role can have very different implications depending on the scheme.
Trace Role Usage
Do not stop at membership. Check where the role is used in permission schemes, notification schemes, workflow conditions, issue security, and any app-owned configuration.
Atlassian documents role usage as a separate view because the same role can be reused in multiple configuration areas.
Separate Role Cleanup From Group Cleanup
Removing a group from a role changes access for that project. Deleting or renaming the group changes a broader object that may affect other projects and Atlassian admin settings.
If the only active reference is a role membership, the safer action may be to remove the group from that role instead of deleting the group.
Validate With Project Owners
Project owners understand whether role members still need the work they can perform. Ask them to approve the specific role change, not a vague group cleanup.
For shared or sensitive projects, validate with representative users after the role membership changes.
Keep Role Evidence
Record which project roles contained the group, what each role controlled, who approved the change, and what the post-change state looks like.
That record matters when a user later reports lost access and the admin needs to explain whether the role cleanup was the cause.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| Group is in a role used by Browse Projects | Whether the role grants project visibility through the active permission scheme. | Require project-owner approval and validate browse access after changes. |
| Group is in a role used only for notifications | Which notifications depend on the role and who owns them. | Treat as communication impact, not necessarily access removal. |
| Group appears in admin-like roles | Whether members still administer the project, workflows, or releases. | Replace with a named owner group or narrower role membership. |
| Role is unused | Whether the role appears in schemes, workflows, security levels, or notifications. | Remove the group from the role only after evidence confirms no active dependency. |
| Same group appears in many project roles | Whether the group is a broad access pattern or migration artifact. | Plan a batch cleanup with owners and a clear baseline. |
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:
- Looking only at permission schemes and missing role membership.
- Removing a group from roles without knowing what the role controls.
- Treating notification impact and permission impact as the same problem.
- Assuming a project owner understands a global group cleanup request.
- Forgetting to validate after role membership changes.
Checklist
- Find every project or space role containing the group.
- Check where each role is used.
- Identify whether the role grants access, notifications, workflow rights, or security visibility.
- Get project-owner approval for changes.
- Validate access after removing or replacing role membership.
- Save before and after role evidence.