To restrict Jira project access, remove or narrow the Browse Projects path in the relevant permission scheme or project role, but only after checking app access, shared-scheme impact, role membership, group ownership, and admin exceptions.
Use this guide to decide the next review route.
Why this matters
Restricting a project is easy to do poorly. A rushed change can lock out the project team, leave a parallel group path open, or change access across every project that shares the same scheme.
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 legal project must be limited to a small team. The admin finds that the current scheme is shared with ordinary delivery projects, so they copy the scheme, narrow Browse Projects, and add only the approved project role.
Pick the right restriction model
For company-managed projects, restrictions usually happen through permission schemes and role membership. For team-managed projects, check the current project access model separately.
Protect yourself from shared-scheme changes
Before narrowing Browse Projects or other permissions, list every project using the scheme. If only one project should change, consider copying the scheme or using role membership.
Narrow Browse Projects first
Visibility usually starts with Browse Projects. Remove public, any logged-in user, application access, or broad group grants only after confirming what replaces them.
Use roles for project-local exceptions
When a shared scheme is otherwise valid, grant permissions to roles and manage membership per project instead of creating one-off direct user grants.
Validate after the change
Use a non-admin test account or Permission helper for a specific work item. Keep before-and-after evidence for owners and audit questions.
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:
- Removing product access when the issue is only one sensitive project.
- Changing a shared permission scheme without checking other projects.
- Leaving Any logged in user or application access on Browse Projects.
- Validating only with a Jira admin account.
Checklist
- Confirm the project type and plan limitations.
- Identify the active permission scheme and all projects using it.
- Review Browse Projects grants and remove broad paths only with a replacement plan.
- Use project roles where access should vary by project.
- Resolve group membership and owners before removing group grants.
- Test with a non-admin account and preserve the evidence.