Permission Scheme Blocks the Very People Who Need to Triage
A service desk team uses a company-managed project with a permission scheme granting "Browse Projects" to group jira-users and "Transition Issues" to group service-agents. A new group, triage-team, was added to the project role "Administrators" so they can manage the project. Triage staff report they can open the project but cannot comment on issues or move them. The project also has issue-level security enabled with a scheme that restricts security level "Internal" to group service-agents. There are 1,200 issues; roughly 300 are marked Internal. The organization uses Atlassian Access with SSO, and group membership is synced from the identity provider.
1. Explain why triage-team can browse but cannot comment or transition, and identify the two independent permission mechanisms at play.
Read the worked answer
Two separate mechanisms govern access here, and both must allow an action.
First, the permission scheme. Being in the project role "Administrators" grants whatever permissions that role is mapped to in the scheme. It does not automatically grant "Add Comments" or "Transition Issues" unless the scheme explicitly maps those permissions to the Administrators role or to a group triage-team belongs to. The scheme grants Transition Issues only to service-agents. So triage-team lacks the transition permission at the scheme level.
Second, issue-level security. Even where the permission scheme allows an action, issue-level security can hide individual issues. The "Internal" level is restricted to service-agents; triage-team is not in that group, so those 300 issues are invisible or inaccessible to them regardless of scheme permissions. This explains why they can browse the project (scheme grants Browse to jira-users, which they likely belong to) but see an incomplete issue set.
The key exam insight: permission schemes and issue-level security are independent gates. A user needs the scheme permission and must pass the issue security check. Diagnosing "can browse but cannot act" requires checking both, plus the user's actual group membership.
2. The team wants triage-team to comment on and transition all issues, including Internal ones. Describe the changes and the security implications.
Read the worked answer
There are two changes, and they should be made deliberately.
Change 1: Permission scheme. Add the triage-team group (or the Administrators project role, if that is the intended abstraction) to "Add Comments" and "Transition Issues". Prefer granting to the project role rather than the raw group so future staffing changes are managed through role membership. Verify that the role membership and group membership actually resolve for a test user, since SSO-synced groups can lag.
Change 2: Issue-level security. To let triage-team see Internal issues, add triage-team to the "Internal" security level. This is a meaningful widening: 300 issues previously restricted to service-agents become visible to a larger population. Confirm with the data owner that triage staff are authorized for that content, and consider whether a narrower approach works, such as a new security level for triage or granting access only to specific issue types.
Security implications: issue-level security is often used for sensitive content (customer PII, security incidents). Widening it should be logged and reviewed. Also check that triage-team does not gain unintended permissions through the Administrators role; project administration can include scheme editing, which is a much broader capability than commenting. If triage only needs to work issues, a dedicated role with limited permissions is safer than the Administrators role.
3. Weeks later, a new triage hire cannot comment despite being added to the group. What is the most likely cause and how do you verify it?
Read the worked answer
The most likely cause is identity-provider sync lag or a group-membership mismatch. With Atlassian Access and SSO, group membership is provisioned from the IdP. Adding a user to a group in the IdP does not instantly reflect in Jira; sync runs on a schedule. The user may also have been added to a similarly named group, or to the IdP group but not the Jira-side group that the permission scheme references.
Verification steps: (1) Check the user's effective group membership in Jira administration, not just the IdP. (2) Confirm the permission scheme maps the permission to a role or group the user actually holds, and check role membership separately from group membership. (3) Use the permission helper to test whether the user has "Add Comments" on a specific issue; this accounts for issue-level security too. (4) Check whether the specific issue is Internal and whether the user is in the Internal security level. (5) Confirm the user is not hitting a workflow condition or a screen configuration issue; a comment field missing from the screen can look like a permission problem.
The disciplined answer is to test with the permission helper first, because it distinguishes scheme permissions from issue security, then check group sync. Do not start by editing the scheme; that risks widening access to fix a provisioning delay.