Review Jira project access by tracing the active permission scheme, Browse Projects grants, role membership, group membership, admin exceptions, and app access before changing users or groups.
Use this guide to decide the next review route.
Why this matters
A project access review fails when it is just a screenshot of the People page. The meaningful answer is the access path: who can see the project, why, who owns that path, and what proof supports a change.
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
Before an audit, a platform team reviews confidential HR and finance projects. They need to show not only who is in each project, but whether access comes from role membership, a shared scheme, or a broad group.
Define the review scope
Start with the project list, risk tier, owner, and whether each project is company-managed or team-managed. Permission schemes are a company-managed project concept, so do not force the same checklist onto every project type.
Map the permission scheme
Record the active scheme, whether it is shared, and all grants for Browse Projects, Administer Projects, Create Issues, Edit Issues, and any sensitive operational permissions.
Resolve groups and roles
Expand roles into users and groups, then expand groups into membership source and owner. This is where many reviews move from a Jira-only task into an Atlassian administration task.
Classify access paths
Use clear lanes such as expected, owner review, remove candidate, externally managed, service account, app/system access, and unknown. Avoid making every row a yes/no decision too early.
Preserve evidence
Keep the project, scheme, grant holder, group or role expansion, owner decision, and action. That evidence matters after the screen changes and the original access path disappears.
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:
- Treating the People page as the whole access review.
- Changing a shared permission scheme without listing affected projects.
- Removing users without understanding group or role paths.
- Failing to preserve evidence after cleanup.
Checklist
- List projects in scope and their owners.
- Separate company-managed and team-managed projects.
- Capture each active permission scheme and whether it is shared.
- Review Browse Projects before deeper permissions.
- Resolve groups and roles into real access paths.
- Record exceptions and owner approvals before changing access.