A Jira permission scheme defines what users, groups, roles, and other grant types can do inside a company-managed project. Treat it as shared infrastructure: one edit can affect every project using the same scheme.
Use this guide to decide the next review route.
Why this matters
Permission schemes are often where project access drift becomes hard to see. A broad group grant, an inherited role, or a shared scheme can expose several projects even when an admin only meant to fix one.
For this question, 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.
Review the group cleanup risk before the Jira change
If this group may be deleted, renamed, replaced, or used in shared permissions, review Group Cleanup Radar first. The useful buying question is whether another reviewer needs exact usage and evidence before the admin changes anything.
Working scenario
A finance project needs tighter visibility after a reorg. The Jira admin finds that the project uses a shared permission scheme, and Browse Projects is granted through both a group and a project role.
What the scheme controls
Explain that the scheme controls in-project capabilities such as browsing, creating, editing, assigning, commenting, and administering. It does not by itself give a user Jira app access.
How grants are usually assigned
Cover groups, project roles, application access, public, any logged-in user, single users, user fields, group fields, reporter, assignee, and project lead grants. For admin guidance, focus on the grants that are easiest to over-broaden: groups, roles, application access, and public-style grants.
Shared scheme impact
Before changing a scheme, identify every project using it. If the scheme is shared, a permission change is a cross-project change, not a local fix.
Permission schemes versus project roles
The scheme can grant a permission to a role, but each project decides who belongs to that role. This is useful for reuse, but it means access tracing must inspect both the scheme and role membership.
A safe review workflow
Document the project, active scheme, sensitive permissions, grant holders, role members, affected projects, and proposed change. Keep a before-state record so the team can explain why access changed later.
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:
- Editing a shared scheme while thinking only about one project.
- Removing a direct user grant while leaving the same access through a group or role.
- Treating project roles as if they were global groups.
- Checking Create Issues but forgetting Browse Projects controls basic visibility.
Checklist
- Confirm the project is company-managed before relying on permission schemes.
- Identify the active permission scheme and whether it is shared.
- Review Browse Projects before other project-level permissions.
- Resolve project-role grants into actual users and groups.
- Record group grants, role grants, public-style grants, and application-access grants separately.
- Keep a before-and-after note for any scheme or membership change.