Permissions
How Access Actually Breaks Down
There is no fixed "Global Admin / Member / No Role" comparison table anymore - access is granted per permission and per scope (global, project, or team). What a given user can do depends on which of these they hold:
| Access Source | Grants |
|---|---|
| Jira Admin (auto-detected) | Everything - every module, every Settings screen, manage any portfolio or report |
| Team Lead / Program Manager (auto-derived from team/program structure) | Elevated access scoped to that team/program - e.g. timesheet approval, plan approval |
| Custom Permission Role (manually assigned) | Whatever permission set an admin built - can be scoped globally, to a program, or to specific teams |
| No assignment | Whatever's left open by default in each module - varies by feature, not a single blanket "read-only" |
Time logging, backlog scoring, and portfolio creation are generally open to any Jira user by default - the granular permission layer controls things like approving timesheets, managing team-scoped reports and plans, and administering global settings.
How Jira Admin Access Works
Jira Admin status is automatically detected - not assigned inside the app. A user is a Jira Admin if they have the Jira site ADMINISTER permission, or belong to the org-admins group, or belong to a jira-admins-* group.
- To grant it: add the user to a qualifying group in Jira user management, or give them the ADMINISTER permission
- To revoke it: remove them from the qualifying group(s)
- The app detects changes automatically on the user's next action - no manual sync needed
Common Permission Scenarios
A new hire needs to start logging time → Time logging is generally open by default; if they're missing something specific (like report access), check whether they need a Permission Role via Settings → Data Access → Permission Roles.
A contractor's engagement has ended → Remove any Permission Role assignments they hold, and remove them as a Team Lead/Program Manager if applicable, via Settings → Data Access.
A team lead was promoted and needs full admin access
→ Add them to a qualifying Jira group (site admin group, org-admins, or jira-admins-*) in Jira user management. The app automatically recognizes them as a Jira Admin.
A user doesn't know why they can't approve a timesheet or see a team's report
→ There's no self-service "My Permissions" screen - ask your Jira admin whether you're a Team Lead/Program Manager for that team, or hold a Permission Role that grants team.approve_timesheets / team.view_worklogs.
A user asks why they can see a portfolio but not edit it → Check that portfolio's Share settings - they may only hold the View role there. Edit or Control access needs to be granted explicitly by whoever holds Control on that portfolio.