Study guide
3.1 Permission Scheme Mechanics & Critical Project Permissions
Atlassian Certified Professional - Jira Administration for Cloud ACP-120
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Blueprint & Jira Cloud Fundamentals
1.1 ACP-120 Exam Structure, Blueprint & Testing Strategy 1.2 Jira Cloud Architecture, Products & Admin Hierarchy
2 Chapter 2: Organizations, Managed Accounts & Global Access
2.1 Atlassian Organizations, Domain Verification & Managed Accounts 2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies 2.3 Site Access, Product Access Tiers & Global Permissions 2.4 User Directory Architecture: Groups vs. Project Roles
3 Chapter 3: Project Permissions & Issue-Level Security Schemes
3.1 Permission Scheme Mechanics & Critical Project Permissions 3.2 Permission Troubleshooting, Additive Permissions & Permission Helper 3.3 Issue Security Schemes, Security Levels & Access Containment
4 Chapter 4: Project Configuration, Types, Versions & Boards
4.1 Company-Managed vs. Team-Managed Project Architecture 4.2 Project Templates, Project Keys & Project Categories 4.3 Project Components, Component Leads & Default Assignees 4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving 4.5 Scrum and Kanban Board Configuration, Board Filters & Columns
5 Chapter 5: Issue Types, Custom Fields, Screens & Schemes
5.1 Standard vs. Sub-task Issue Types & Issue Type Schemes 5.2 Custom Field Types, Global vs. Project Contexts & Options 5.3 Field Configurations, Renderers, Hiding & Required Fields 5.4 Screens, Screen Schemes & Issue Type Screen Schemes
6 Chapter 6: Workflows — Company-Managed and Team-Managed
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions 6.2 Transition Rules: Conditions vs. Validators 6.3 Post Functions, Execution Order & Resolution Management 6.4 Workflow Schemes, Editing Active Workflows & Status Migration 6.5 Team-Managed Workflows, Statuses & Workflow Rules
7 Chapter 7: Jira Cloud Automation
7.1 Automation Engine, Rule Architecture & Event Triggers 7.2 Automation Conditions, Smart Values & String/Date Expressions 7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics 7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
8 Chapter 8: Notifications, Events, Personal Settings & Mail Handlers
8.1 Jira Events, System Events & Notification Schemes 8.2 Notification Recipients, Custom User Fields & Deduplication 8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email 8.4 Mail Handlers: Creating Issues and Comments from Email
9 Chapter 9: JQL, Filters, Dashboards & Bulk Operations
9.1 JQL Fundamentals, Clauses, Operators & History (WAS / CHANGED) 9.2 Advanced JQL Functions & Dynamic Date Searches 9.3 Filter Permissions, Shared Filters & Filter Subscriptions 9.4 Dashboard Layouts, the Default Dashboard, Sharing & Essential Gadgets 9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
10 Chapter 10: System Administration
10.1 Global UI Features: User Defaults, Look and Feel, Announcement Banner & Default Dashboard 10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration 10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links 10.4 System Backup, Restore & Data Import
3.1 Permission Scheme Mechanics & Critical Project Permissions
Key Takeaways Explain This Topic AI
Permission schemes map project permissions to users, groups, project roles, and dynamic actors across company-managed projects.
The Browse Projects permission is the mandatory baseline gatekeeper; without it, users cannot access the project, search its issues, or view tickets on boards.
The Assign Issues permission grants the ability to change the assignee, whereas Assignable User determines who can appear in the Assignee dropdown selection.
Project Roles decouple permission schemes from global user directories, allowing project administrators to manage membership locally without global Jira administrative privileges.
Administer Projects covers role membership, components, versions, and project details, but changing the project key, editing shared schemes, and creating fields or statuses need a Jira admin.
Last updated: September 2026
Permission Scheme Architecture & Critical Project Permissions
In Jira Cloud, access control for company-managed projects is governed by Permission Schemes . A permission scheme is a centralized, reusable matrix that maps individual project-level permissions to specific entities—such as project roles, user groups, and dynamic issue actors. Understanding how permission schemes function, how grants are evaluated, and the precise boundaries of project administration is critical for managing enterprise Jira Cloud sites and succeeding on the ACP-120 exam.
Company-Managed vs. Team-Managed Permission Models
Before exploring permission schemes, it is vital to distinguish between Jira's two project architectures:
Company-Managed Projects: Use shared configuration schemes (permission schemes, issue type schemes, workflow schemes, screen schemes). Access control is centralized and standardized across the Jira site, managed by Jira Administrators with delegated membership control given to Project Administrators through Project Roles.
Team-Managed Projects: Do not use permission schemes. Instead, they use self-contained, project-specific access levels ( Open , Limited , Private ) with localized roles ( Administrator , Member , Viewer ) managed completely inside the individual project settings.
The remainder of this chapter focuses on company-managed projects , where permission schemes and issue security schemes operate.
The Architecture of Permission Schemes
A permission scheme consists of approximately 40 distinct permissions categorized into logical functional groups. A single permission scheme can be associated with multiple company-managed projects. When an administrator modifies a shared permission scheme, the changes immediately apply to every project associated with that scheme. +-------------------------------------------------------------+
- | Shared Permission Scheme |
- | - Browse Projects --> Project Role: Service Desk Team |
- | - Create Issues --> Group: jira-software-users |
- | - Edit Issues --> Project Role: Developers |
- | - Administer Projects --> Project Role: Administrators |
- +-------------------------------------------------------------+
- | |
- v v
- +-------------------+ +-------------------+
- | Project Alpha | | Project Beta |
- | (Role Members A) | | (Role Members B) |
- +-------------------+ +-------------------+
- Permitted Entity Grant Types
Jira lets you grant each permission in a scheme to several kinds of entity:
Grant Type Description Administrative Best Practice & Governance
Project Role A project-specific bucket of users and groups (e.g., Developers , Administrators ). Recommended standard. Decouples scheme logic from user administration. Allows project admins to add/remove users locally without requiring global Jira Admin rights.
Group A global set of users managed in Atlassian Administration (e.g., jira-software-users , finance-department ). Use sparingly for organization-wide baselines. Adding groups directly couples project access to global user management.
Single User A specific, hardcoded Atlassian account ID. Anti-pattern. Creates technical debt and administrative overhead when employees leave or change teams. Never recommended on ACP-120 scenarios.
Reporter Dynamic actor: The user who created the issue. Excellent for self-service empowerment (e.g., allowing reporters to edit or close their own tickets).
Current Assignee Dynamic actor: The user currently assigned to the issue. Ideal for workflow security (e.g., allowing only the current assignee to log work or execute specific transitions).
Project Lead Dynamic actor: The single user designated as the lead in project settings. Useful for escalation workflows or designated default project approvals.
Service Project Customer Portal-only customers in Jira Service Management (JSM). Applies only to JSM projects to allow external portal users to raise requests.
User / Group Custom Field Value Dynamic actor based on a User Picker or Group Picker custom field on the issue. Powerful for governance workflows (e.g., granting edit permissions to whoever is selected in an "Approver" custom field).
Any logged-in user / app access Anyone signed in to the site, or anyone with access to the Jira app. Makes a project broadly visible inside the company. Browse Projects doesn't require app access.
Public (anyone on the web) Anonymous visitors. Only for deliberately public projects. Free sites can't be made public.
Core Permission Categories & Critical Permissions
Jira organizes permissions into six primary categories. Administrators must master the exact behavior and administrative implications of each.
1. Project Permissions
Browse Projects: The single most critical permission in Jira. It determines whether a user can see the project, view its issues in search results, view agile boards, open project pages, or receive project notifications. If a user lacks Browse Projects , the project effectively does not exist for them (navigating directly to an issue URL returns an error indicating the issue does not exist or access is denied).
Administer Projects: Grants delegated administration of the project. It allows managing components, versions, project role memberships, and localized settings.
2. Issue Permissions
Create Issues: Governs whether a user can open the global Create modal and create new issues within this specific project.
Edit Issues: Allows modifying field values on existing issues (via the Edit dialog or inline editing on the issue view).
Assign Issues: Governs whether a user can perform the act of assigning an issue (changing the value in the Assignee field).
Assignable User: Governs whether a user's name can be selected as an assignee .
Close Issues: Allows transitioning issues into a status in the "Done" category where the transition is guarded by closure permissions.
Resolve Issues: Allows resolving and reopening issues, including setting the Fix Version/s field.
Schedule Issues: Governs the ability to populate and edit the Due Date field and drag issues across timelines/roadmaps.
Delete Issues: Allows permanently deleting issues from the database. In enterprise environments, this permission should be strictly restricted to Jira Administrators or removed entirely, replacing deletion with an "Archived" or "Cancelled" workflow status.
Move Issues: Governs moving issues between projects (or between workflows in the same project). To move an issue into another project, the user also needs Create Issues in the destination project.
Modify Reporter: Allows changing the user recorded in the Reporter field.
Set Issue Security: Governs whether a user can view and change the Security Level field on issues when an Issue Security Scheme is applied.
3. Comments, Attachments & Time Tracking
Comments: Includes Add Comments , Edit All Comments , Edit Own Comments , Delete All Comments , and Delete Own Comments .
Attachments: Includes Create Attachments , Delete All Attachments , and Delete Own Attachments .
Time Tracking: Includes Work On Issues (logging work against an issue), Log Work for Others , Edit Own Worklogs , Edit All Worklogs , Delete Own Worklogs , and Delete All Worklogs .
4. Voters & Watchers
View Voters and Watchers: Allows seeing the list of users voting for or watching an issue.
Manage Watchers: Allows adding or removing other users to/from the watchers list of an issue.
The Critical Interplay: Assign Issues vs. Assignable User
A frequent stumbling block on the ACP-120 exam is the operational distinction between Assign Issues and Assignable User : +------------------------------------+ +------------------------------------+
- | Assign Issues | | Assignable User |
- | The *Actor* performing the act | ----> | The *Target* receiving the work |
- | "Can I change the Assignee field?" | | "Can my name appear in the list?" |
- +------------------------------------+ +------------------------------------+
Consider the operational matrix:
User has Assign Issues , but NOT Assignable User : The user (e.g., a Project Manager or Scrum Master) can reassign issues to developers, but they cannot assign an issue to themselves, nor can any other user assign an issue to them.
User has Assignable User , but NOT Assign Issues : The user (e.g., a Junior Developer or External Contractor) can be assigned tickets by team leads, but they cannot reassign tickets to other team members or even unassign themselves.
User lacks both: The user cannot change assignments and cannot receive assignments.
Exam Trap: Remember that to be an Assignable User , a user must also possess the Browse Projects permission. If an administrator adds a user to a group granted Assignable User but omits Browse Projects , the user will never appear in the assignee dropdown menu.
Specific Permissions Beat General Ones
Atlassian documents that when two permissions overlap, the more specific permission decides . Edit Issues normally lets a user change any field, including Assignee. Once you configure Assign Issues in the scheme:
- only users with Assign Issues can change the Assignee field;
- users with only Edit Issues can change every other field, but not Assignee;
users with Assign Issues but not Edit Issues can change only the Assignee field.
Delegated Project Administration: Boundaries & Cloud Guardrails
The Administer Projects permission delegates significant autonomy to project leads and managers without granting full Jira Administrator rights. However, clear boundaries exist between what a Project Administrator can do versus what requires a global Jira Administrator.
- Capability Project Administrator ( Administer Projects ) Jira Administrator (Global Permission)
- Manage Versions (create, release, archive, unrelease) Yes Yes
- Manage Components (create, edit, set component leads/default assignees) Yes Yes
- Manage Project Role Membership (add/remove users from roles) Yes Yes
- Update Project Details (name, URL, lead, description, avatar) Yes Yes
- Change the Project Key or Assign a Project Category (company-managed) No Yes
- Create Project Automation Rules (scoped only to this project) Yes Yes
- Associate/Change Schemes (Permission, Issue Type, Workflow, Screen) No Yes
- Create New Custom Fields No Yes
- Create New Global Statuses No Yes
- Create or Modify Global Permission Schemes No Yes
- Create Global Automation Rules (multi-project or global) No Yes
- Edit Workflows and Manage Work Item Layouts
Jira Cloud has replaced the old Extended project administration permission with two narrower project permissions, both granted in the permission scheme and both requiring Browse Projects :
Edit workflows: Lets the holder update statuses and transitions in the project's workflow using the workflow editor, but only if no other project uses that workflow .
Manage work item layouts: Lets the holder change which existing fields appear on the project's issue layout, but only if the layout's screens aren't shared with other projects. It doesn't allow creating new custom fields.
If the workflow or screens are shared, the change needs the Administer Jira global permission. To delegate workflow changes to one team, a Jira admin can copy the shared workflow, map the copy to that project's workflow scheme, and then grant Edit workflows in the project's permission scheme.
A separate Manage versions (releases) permission lets users create, release, archive, merge, edit, and delete versions without full project administration.