Jira project roles are per-project membership containers. A permission scheme can grant a permission to a role, but users only receive that permission in projects where they are role members.
Why this matters
Roles make shared permission schemes workable, but they also hide access behind another layer. An admin cannot understand project access by looking only at the scheme or only at the People page.
For the query jira project roles, 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 team wants contractors to see one delivery project but not the rest of the portfolio. The site uses a shared scheme, so the admin grants Browse Projects to a project role and adds the contractor group only in the allowed project.
What a project role is
Describe a role as a reusable placeholder in Jira permissions, notifications, work item security, and workflow rules. The role exists across Jira, but membership is resolved per project.
Why roles are different from groups
Groups are organization-level membership lists. Roles are project-level assignments that can contain users or groups. A group in a role still needs the scheme to grant that role a permission.
Where role membership creates access
A user gains a role-backed permission only when the permission scheme grants that permission to the role and the user is in that role for the project being checked.
Default members and new projects
Mention default role members cautiously. Broad default groups can create access as new projects are created, so review them before using roles as a cleanup tool.
Role review evidence
For an access review, capture the role, project, role members, group owners, scheme permissions that reference the role, and any exceptions that should not be changed.
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:
- Assuming a role grant gives the same people access in every project.
- Adding a global group directly to a scheme when a project role would isolate the access better.
- Reviewing role names without expanding actual members.
- Forgetting that default members can create future access drift.
Checklist
- List each project role referenced by the permission scheme.
- Resolve every role into users and groups for the project being reviewed.
- Check default role members before creating or changing projects.
- Separate app/system roles from human access roles.
- Confirm whether group membership is local, default, or externally managed.
- Keep role membership evidence with the project access decision.