Why this matters
Permission mistakes in Jira are rarely dramatic at first. They show up as slow, annoying questions:
- why can a contractor still browse a project after offboarding?
- why can a new user log in but see nothing useful?
- why did changing one scheme affect five projects?
- why did removing someone from a group not actually remove their access?
Those questions have operational consequences. Access reviews take longer. Cleanup becomes riskier. Admins fall back to screenshots and memory instead of a repeatable review path. And once a Jira site gets bigger, partial understanding becomes expensive. You can still click around and eventually find the answer, but that is not the same thing as having a clean, defendable access model.
Atlassian's current documentation also reinforces that Jira access is layered. App access is granted in Atlassian Administration through roles and groups, while in-app permissions are a separate layer used to control what users can do inside Jira projects. Global permissions sit above project-level permissions and apply across the site, while permission schemes can be shared by multiple projects. That is the structure behind most permission surprises.
The four layers that matter
The cleanest way to understand Jira permissions is to separate four different objects that admins often blur together.
1. Groups
Groups are containers for users. In Atlassian Administration, they are used to manage people who need the same permissions or restrictions. That sounds simple, but groups do two very different jobs:
- they can help grant app access
- they can also be referenced inside Jira permission schemes or other in-app permission models
That dual role is where confusion starts. A group is not itself a permission scheme, and it is not the same thing as a project role. It is a reusable identity container that can be attached to many access decisions.
2. Project roles
Project roles are placeholders inside a project. Atlassian's documentation describes them as a way for Jira admins to grant permissions in a scheme without explicitly defining the final users in every project. That is why roles are useful: they let the same permission scheme work across multiple projects while project-level admins decide who fills those roles in each project.
That makes roles more contextual than groups. A group usually means "these people belong together." A role usually means "these people do this job in this project."
3. Permission schemes
Permission schemes define what users can do inside a project. They are the middle layer that actually grants actions like browsing projects, editing issues, transitioning work, or administering a project.
The important detail many admins miss is that permission schemes can be shared. Atlassian explicitly notes that changes to a shared scheme apply to every project that uses it. So when you edit a scheme, you are not just changing one project. You may be changing several.
4. Global permissions
Global permissions sit above the project layer. Atlassian describes them as permissions that apply across the entirety of your site. These are the rights that control things like broad site-level capabilities and administrative power. They are not a substitute for project permissions, and project permissions are not a substitute for them.
That sounds obvious until you troubleshoot a user who can log in, create filters, browse people, or administer Jira, yet still cannot browse a particular project because the project-level layer is separate.
How groups, roles, and schemes actually interact
The easiest way to make the model real is to trace one user.
Imagine a new contractor named Maya joins the delivery team.
First, Maya gets app access to Jira. In Atlassian Administration, that may happen because:
- she is assigned a role directly when invited
- she is added to a group that grants Jira app access
- she is provisioned through SCIM and lands in a synced group that maps to Jira access
At this point, Maya can access Jira as an app. That still does not guarantee she can browse the specific projects she needs.
Next, inside Jira, one of two common things happens:
- Maya is added directly to a group that a permission scheme uses
- Maya is assigned to a project role, and the permission scheme grants rights to that role
Now Maya can browse a project, comment, transition work, or do whatever the scheme allows. If that project shares its permission scheme with other projects, the same structure may affect several places at once.
This is also why "remove from group" can fail as a mental model. Maya may still retain access because:
- she belongs to another group that grants the same permission
- she also sits in a project role
- the project uses a shared scheme and another path still grants the permission
The result is that one user can have multiple access paths at the same time. Jira supports that. The admin pain appears when no one has traced those paths cleanly.
A quick comparison table
| Construct | What it is | Best use | Common mistake |
|---|---|---|---|
| Group | Identity container for multiple users | Reuse membership for app access and in-app permission references | Treating a group like a permission model instead of a building block |
| Project role | Project-scoped placeholder for responsibilities | Letting projects use the same scheme without hardcoding users everywhere | Using roles and groups as if they were interchangeable |
| Permission scheme | Rule set for what users can do in a project | Defining browse, edit, transition, admin, and related rights | Forgetting one scheme can be shared by many projects |
| Global permission | Site-wide capability | Controlling broad Jira powers across the site | Assuming global permissions explain project access |
What people often miss
This is the section that usually matters most in practice.
Product access is not the same thing as project access
Atlassian separates app access from in-app permissions. A user can have Jira access and still fail to see the project they need. That is why "they have Jira, so why can't they see the project?" is such a common admin question.
The reverse problem is also real. A user can inherit more access than intended because the group that grants app access also becomes entangled with broader permission decisions later.
Shared schemes hide blast radius
Admins often think they are editing one project when they are editing a shared permission scheme. That is fine when the scheme is intentionally standardized. It becomes risky when the admin does not realize how many projects share it.
This is one reason permission cleanup gets avoided. The work is not technically impossible. It is just harder to review safely than it first appears.
Roles and groups solve different problems
Groups are better for identity and reusable membership. Roles are better for project-scoped meaning. If you use groups where a role would be cleaner, you tend to create brittle permission design. If you use roles without understanding the groups behind them, you create cleanup surprises later.
Global permissions explain power, not every path
Global permissions matter because they change what users can do across the site. But they are not the whole story of access. A user can be missing the exact project permission they need even while holding significant site-wide capability. That is one reason Jira permission troubleshooting feels contradictory until the layers are separated.
A practical checklist for tracing Jira access
When you need to answer "Why does this person have access?" or "What breaks if I change this group?" run the question in this order:
- Confirm app access first.
- Does the user actually have Jira app access through a role or group in Atlassian Administration?
- Check whether the project permission comes from a group or a role.
- If it is a role, who is assigned to that role in the project?
- If it is a group, where else is that group used?
- Identify the permission scheme in use.
- Is the scheme unique to this project or shared with others?
- Check for duplicate paths.
- Does the user have the same effective access through another group or role?
- Separate site-wide from project-specific power.
- Are global permissions relevant here, or are you really dealing with project-level access?
- Review the change blast radius before editing anything.
- Who else will be affected?
- Which other projects reuse the same scheme or role model?
This sequence does not solve every access question instantly, but it stops the most common admin mistake: changing the first visible object instead of the actual granting path.
When native Jira stops being enough
Native Jira is enough to learn the model. It is enough for many quick checks. The problem begins when the task shifts from understanding permissions to proving impact before a change.
That is the turning point where admins stop asking, "Can I technically inspect this?" and start asking, "Can I review it cleanly without missing something?"
If you are reviewing the impact of a group change across permission schemes and project roles, the hard part is no longer the definition of a role or scheme. The hard part is assembling a trustworthy pre-change view. That is the job Group Impact Audit for Jira is built around: read-only review of where a Jira group still matters before cleanup, rename, or removal. If you are still deciding whether native Jira is enough, start with the comparison page for native Jira review vs Group Impact Audit for Jira and the Jira group cleanup use case.
What to do next
If this article clarified the model but you still need a safer review path, the next steps should match your problem:
- If groups are still the confusing part, read How Jira Groups Actually Work.
- If you are deciding between design approaches, read Jira Project Roles vs Groups.
- If you are about to change a group, use the Jira group cleanup use case and compare native Jira review with Group Impact Audit for Jira.
The important move is not memorizing every permission label. It is learning how to trace access without guessing, and how to review changes without pretending one screen tells the whole story.
FAQ
What is the difference between Jira groups and project roles?
Groups are reusable sets of users. Project roles are project-scoped placeholders that let the same permission scheme work across multiple projects without hardcoding the final users everywhere.
What does a Jira permission scheme control?
A permission scheme controls what users can do inside a project. It defines rights like browsing projects, editing issues, transitioning work, or administering the project.
What are global permissions in Jira?
Global permissions are site-wide permissions. They control capabilities that apply across the Jira site rather than inside one specific project.
Can one user get access through multiple paths?
Yes. A user can have app access through one group, project access through a role, and the same effective permission through more than one group or scheme path. That is exactly why access review gets messy if you only check one layer.