Jira global permissions control site-wide or cross-project capabilities such as Jira administration, bulk changes, browsing users and groups, and sharing. They are not the same as project permissions.
Why this matters
A global permission can give a group broad power even if individual project permissions look clean. Admins should review global grants separately from project access and record why each broad grant exists.
For the query jira global permissions, 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
An audit asks why a group of power users can make bulk changes across Jira. The project schemes do not explain it; the answer is a global permission grant to a group that has grown over time.
What global permissions cover
Explain that global permissions operate across the Jira site and govern non-project-specific capabilities. Examples include Administer Jira, Browse users and groups, Share dashboards and filters, and Make bulk changes.
What global permissions do not prove
A global grant does not fully explain ordinary project visibility. Project access still depends on app access, Browse Projects, permission schemes, groups, roles, and sometimes work item security.
High-risk grants to review
Prioritize Administer Jira, Make bulk changes, public-style grants, and any broad group that mixes admins, contractors, service accounts, and normal users.
Group ownership and membership
Because global permissions are often granted to groups, the review needs group ownership, source of membership, and evidence that current members still need the site-wide capability.
Review cadence
Review global permissions on a slower but formal cadence than project access: after admin team changes, before audits, and before granting broad groups new platform-level power.
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:
- Using global permissions as the only explanation for project visibility.
- Leaving former admins in groups that grant Administer Jira.
- Reviewing group names without checking membership source.
- Removing a broad grant without confirming who owns the operational capability.
Checklist
- Export or record current global permissions and their grant holders.
- Separate admin-level capabilities from user convenience capabilities.
- Resolve group grants into owners, members, and membership source.
- Check whether any grant uses Anyone or another broad holder.
- Record why each broad grant is still required.
- Route project visibility questions back to permission schemes and Browse Projects.