In Jira, groups hold users across Atlassian administration, project roles hold users or groups per project, and permission schemes grant project permissions to groups, roles, users, and other holders.
Why this matters
These three concepts are often mixed together during access reviews. Clean permissions depend on using each layer for the right job and tracing how they combine for a specific user and project.
For the query groups roles permission schemes jira, 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 department group should have access to one project but not another. The safer design is often a project role in the shared scheme, with the group added to that role only in the intended project.
Groups
Groups are organization-level membership containers. They can grant app access, global permissions, project permissions, and role membership, so changing one group can have wide impact.
Project roles
Project roles are project-local assignments. They let a shared permission scheme stay reusable while each project controls who fills the role.
Permission schemes
Permission schemes define which holders receive which project permissions. They are powerful because they can be shared, and risky because one grant can affect many projects.
How the layers combine
A user might gain Browse Projects because they are in a group, because the group is in a role, and because the permission scheme grants Browse Projects to that role. Review the full chain.
Which layer to change
Change group membership when the user's organizational entitlement is wrong. Change role membership when one project needs a different member set. Change the scheme when the permission model itself is wrong.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| Whether the user has product access before project permissions matter | Confirm the current state, owner, and source before acting. | Preserve the reason and evidence in the review record. |
| Which permission scheme controls the project | Confirm the current state, owner, and source before acting. | Preserve the reason and evidence in the review record. |
| Which project roles include the group or user | Confirm the current state, owner, and source before acting. | Preserve the reason and evidence in the review record. |
| Whether Browse Projects is granted through more than one path | Confirm the current state, owner, and source before acting. | Preserve the reason and evidence in the review record. |
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:
- Putting every exception directly into the permission scheme.
- Using project roles without checking their actual members.
- Deleting a group because no one checked its role and scheme references.
- Creating duplicate schemes instead of using roles for local membership differences.
Checklist
- Identify whether the access path starts with app access, a group, a role, or a scheme grant.
- Use groups for broad owned membership, not as a quick one-project exception.
- Use roles for per-project membership differences.
- Use schemes for the permission model, not as a membership list.
- Check shared-scheme impact before changing scheme grants.
- Record every group reference that supports the final decision.