Short definition
A permission scheme in Jira is a named set of mappings from permissions (Create Issues, Edit Issues, Transition Issues, etc.) to the users, groups, or project roles that can perform them. Each project is assigned exactly one permission scheme. Schemes are reusable: one scheme can be shared by many projects, so a single edit propagates everywhere it's used.
What permissions are managed
A permission scheme covers ~30 permissions across categories:
- Project: Administer Projects, Browse Projects.
- Issue: Create, Edit, Delete, Assign, Assignable User, Resolve, Move, Link, Schedule, Modify Reporter, Set Issue Security.
- Comments: Create, Edit Own, Edit All, Delete Own, Delete All.
- Attachments: Create, Delete Own, Delete All.
- Time Tracking: Work On Issues, Edit Own/All Worklogs, Delete Own/All Worklogs.
- Voters & Watchers: View, Manage.
Each permission is assigned to one or more of: Application access (any logged-in user), Project Role, Group, User, Single user in custom field, Group in custom field, Project Lead, Current Assignee, Reporter.
Scheme reuse
A scheme is meant to be shared across multiple projects. Typical pattern in a large Jira instance:
- One standard scheme for most projects.
- A restricted scheme for projects with sensitive data (locked-down editing, narrower role references).
- A JSM scheme for service-desk projects (different permission shape - customers vs. agents).
Adding a project to an existing scheme costs nothing operationally. Forking a scheme - copying it just for one project’s special case - is where complexity accumulates. Be deliberate about when a new scheme is warranted vs. when an existing one should be edited.
Common patterns
Three useful idioms:
- All permissions reference roles, not users. This is the abstraction that lets schemes scale.
- Default Assignee + Assignable User aligned. If only Developers can be assigned, only Developers should be eligible to be set as assignee.
- Edit Issues granted, Edit Own Comments granted, Edit All Comments restricted. Lets every user edit their own typos but prevents rewriting other people’s words.
Auditing permission schemes
Two recurring questions worth asking periodically:
- Which projects use which scheme? Helps identify orphan schemes (no projects assigned - candidates for deletion) and over-shared schemes (a special-case change risks affecting unrelated projects).
- Who can edit permission schemes? Permission-scheme edits change access for every project using the scheme. In regulated environments, restricting this and auditing changes - which Secure Admin for Jira does at a more granular level than vanilla Jira - is good practice.
See also (Redmoon products)
Common questions
What is a permission scheme in Jira?
A permission scheme in Jira is a named set of mappings from permissions (Create Issues, Edit Issues, Transition Issues, etc.) to the users, groups, or project roles that can perform them. Each project is assigned exactly one permission scheme. Schemes are reusable: one scheme can be shared by many projects, so a single edit propagates everywhere it's used.
What's the difference between project permissions and global permissions?
Global permissions (Jira System Administrator, Browse Users, etc.) are instance-wide and granted in global admin. Project permissions are per-project and granted via a permission scheme assigned to that project. A user can have global Browse Users but no project permissions - they can find users but can't see any issues.
How do I copy a permission scheme?
In Jira admin -> Issues -> Permission schemes, find the source scheme and choose Copy. The copy starts as an exact duplicate; edits affect only the copy. Use this pattern when one project needs slightly different permissions - copy the existing scheme, modify, and assign the new scheme to just that project.
Why do permission schemes mostly reference project roles instead of users?
Because roles let the scheme stay project-agnostic. A scheme that grants Edit Issues to 'Project Role: Developers' works correctly in every project - each project decides who its developers are. A scheme that grants Edit Issues to a specific user only works in projects where that user belongs, and edits require admin every time someone joins.