Browse Projects is the Jira permission that lets a user view a project and search or see its work items, subject to work item security. It is usually the first permission to check in a project visibility problem.
Why this matters
Many access problems look confusing because app access, project visibility, and work item visibility are mixed together. Browse Projects is the pivot point for company-managed project visibility.
For the query browse projects permission jira, 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 new employee can open Jira but sees only the dashboard. The admin checks the project permission scheme and finds the employee has app access but no Browse Projects path through a group or role.
What Browse Projects allows
Explain that the permission lets users view the project, see work items, and search for them unless work item security restricts individual work items.
What it does not allow
Browse Projects does not automatically let users create, edit, transition, assign, delete, administer, or see work hidden by work item security. Those are separate permissions or controls.
Common grant holders
Review groups, project roles, application access, public, any logged-in user, and field-based grants. These holders have very different review implications.
Visibility edge cases
Some field-based grants can make project names visible in broader listings without granting full work item visibility. Write about this cautiously and send admins to Atlassian's current docs.
How to change it safely
Do not remove Browse Projects broadly until the admin knows whether the grant is shared, what other projects use the scheme, and which groups or roles depend on it.
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 Jira app access is the same as Browse Projects.
- Using broad group grants because they are faster than role membership review.
- Forgetting work item security when work items are the actual symptom.
- Changing Browse Projects in a shared scheme without impact analysis.
Checklist
- Confirm the symptom: project list visibility, work item visibility, or create-work dropdown visibility.
- Check app access before checking project permissions.
- Find Browse Projects in the active permission scheme.
- Resolve each grant holder into users, groups, or role members.
- Check whether work item security explains hidden work items.
- Record shared-scheme impact before changing the grant.