Study guide
2.4 User Directory Architecture: Groups vs. Project Roles
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
2.4 User Directory Architecture: Groups vs. Project Roles
Key Takeaways Explain This Topic AI
Groups are globally defined collections of users across an organization, whereas Project Roles are global identifiers whose membership is defined independently inside each project.
Assigning project permissions exclusively to Project Roles eliminates scheme sprawl, enabling hundreds of projects to share a single master permission scheme.
Project Roles empower Jira Administrators to delegate project-level access management to Project Leads without granting them global Jira Administrator permissions.
Default role members automatically populate new projects upon creation, but modifying default members does not retroactively change existing projects.
Team-managed projects have no permission schemes; they use Open, Limited, or Private access levels plus Administrator, Member, Viewer, and custom roles.
Last updated: September 2026
2.4 User Directory Architecture: Groups vs. Project Roles
Quick Summary: Designing a scalable user directory architecture is the single most important skill for a Jira Cloud Administrator. The ACP-120 exam rigorously tests the strategic differences between Groups (static, global collections of users managed by system admins) and Project Roles (dynamic, context-sensitive abstractions whose membership is delegated to project leads). Mastering role-based permission schemes eliminates scheme sprawl , preserves system performance, and drastically reduces administrative overhead.
Fundamental Comparison: Groups vs. Project Roles
In Jira Cloud, user authorization relies on two core constructs: Groups and Project Roles. Understanding their operational scope, management delegation, and architectural lifecycle is critical for the exam.
Architectural Attribute Groups Project Roles
Definition Scope Global across the entire Atlassian Organization / Site. Defined globally by Jira Admins, but membership is evaluated per project.
Membership Scope Static: A user is either in a group globally or not. Contextual: A user can be a 'Developer' in Project A, a 'Viewer' in Project B, and have no role in Project C.
Membership Management Organization-level admins in Atlassian Administration, or an external IdP via SCIM. (Jira admins can't manage users.) Delegated to project admins via Project settings > Access (People).
Primary Use Cases Granting Product Access (licensing); Global Permissions; bulk email subscriptions. Assigning permissions in Permission Schemes, Issue Security Schemes, Notification Schemes, and Workflow Transition rules.
Delegation Capability Cannot be delegated to business users without granting global admin rights. Fully delegated to individual project owners without giving them system admin rights.
Scheme Reusability Poor: Tying schemes to specific groups forces the creation of new schemes for every team. Exceptional: Hundreds of projects can share one master scheme while maintaining independent membership. +-------------------------------------------------------------------------+
- | GLOBAL SYSTEM DIRECTORY |
- | User: Alice (alice@acme.com) |
- | Groups: jira-software-users, mobile-developers |
- +-------------------------------------------------------------------------+
- |
- +---------------------------+---------------------------+
- | |
- v v
- +-----------------------------------+ +-----------------------------------+
- | PROJECT: MOBILE APP | | PROJECT: CORE PLATFORM |
- | Shared Scheme: Standard Perms | | Shared Scheme: Standard Perms |
- | | | |
- | Role: Administrators -> Lead Bob | | Role: Administrators -> Lead Dave|
- | Role: Developers -> ALICE | | Role: Developers -> Charlie |
- | Role: Viewers -> QA Group | | Role: Viewers -> ALICE |
- | | | |
- | (Alice can EDIT & RESOLVE issues)| | (Alice can ONLY READ issues) |
- +-----------------------------------+ +-----------------------------------+
- Eliminating the "Scheme Sprawl" Anti-Pattern
In novice Jira implementations, administrators frequently fall into the Scheme Sprawl Trap . When Team Mobile requests custom permissions, the administrator copies the Default Permission Scheme, names it "Mobile Permission Scheme", and hardcodes the group mobile-team into the "Edit Issues" permission. Six months later, with 100 development teams, the instance possesses 100 distinct permission schemes.
The Operational Disaster of Scheme Sprawl
Administrative Nightmare: When corporate security mandates that "Delete Issues" must be restricted to project leads across all projects, the Jira Administrator must manually update 100 separate schemes.
Audit Difficulty: With hundreds of near-identical schemes, nobody can quickly answer "who can delete issues where?", which makes security reviews slow and error-prone.
Loss of Self-Service: Project leads cannot manage their own team members. Every new hire requires an IT support ticket to add the user to a specific global group.
The Golden Rule: The Role-Based Architecture
To scale Jira Cloud effectively, follow the industry-standard Role-Based Architecture :
Define Standard Project Roles: Navigate to Jira Settings > System > Project roles . Establish clean, functional roles such as:
- Administrators (Project owners)
- Developers (Core contributors who create, edit, transition, and resolve issues)
- Testers / QA (Can create bugs, add attachments, verify fixes)
- Viewers / Stakeholders (Read-only access, can add comments)
- Service Desk Customers (External requestors)
Build One Master Permission Scheme: Create a single, standardized Permission Scheme where permissions are mapped exclusively to these Project Roles :
- Administer Projects -> Project Role: Administrators
- Browse Projects -> Project Roles: Administrators , Developers , Testers , Viewers
- Create Issues / Edit Issues -> Project Roles: Administrators , Developers , Testers
- Resolve Issues / Close Issues -> Project Roles: Administrators , Developers
- Delete Issues -> Project Role: Administrators
Associate All Projects with the Master Scheme: Apply this single scheme to all 100+ company-managed projects.
Delegate Membership to Project Leads: Project Leads manage who belongs to their project team directly within Project Settings > Access (or People ). Adding Alice to the "Developers" role in Project Mobile immediately grants her the exact permissions required, without Jira Admin intervention and without modifying the shared scheme!
Default Role Members: Mechanics & Exam Nuances
When a Jira Administrator defines a Project Role in global settings ( Jira Settings > System > Project roles ), they can configure Default Members (default users and default groups). +-------------------------------------------------------------------------+
- | GLOBAL PROJECT ROLE CONFIGURATION |
- | |
- | Role Name: Developers |
- | Description: Software engineers and core technical contributors |
- | |
- | Default Users: [ None ] |
- | Default Groups: [ engineering-all ] |
- +-------------------------------------------------------------------------+
- |
- | (Admin creates NEW Project)
- v
- +-------------------------------------------------------------------------+
- | NEW PROJECT: 'PAYMENTS' CREATED |
- | |
- | Role 'Developers' Automatically Initialized With: |
- | - Group: engineering-all |
- +-------------------------------------------------------------------------+
- |
- [ CRITICAL EXAM BEHAVIOR ] |
- Updating Default Members later in Global Settings has ZERO retroactive |
- effect on existing projects! It ONLY stamps onto newly created projects.|
- +-------------------------------------------------------------------------+
- The Retroactivity Trap
A classic ACP-120 exam question tests what happens to existing projects when an administrator modifies default role members:
Behavior on Project Creation: When a new project is created, Jira copies the globally configured default users and groups into that project's role roster.
Zero Retroactive Propagation: Modifying default role members in Global Settings does NOT retroactively update existing projects ! If an administrator adds the group security-auditors to the default members of the "Viewers" role, existing projects are completely unaffected. To add the group to existing projects, administrators must update each project's role membership individually or execute a REST API script.
IdP Synchronization & Nested Group Limitations in Cloud
In on-premises Active Directory or legacy Jira Data Center deployments connected via LDAP, organizations frequently utilized Nested Groups (e.g., the group mobile-engineers is placed inside core-engineers , which is placed inside jira-software-users ). Users inherited permissions recursively.
The Jira Cloud Nested Group Limitation
Fundamental Architectural Rule: Jira Cloud does NOT support nested groups!
When user directories and groups are synchronized to Atlassian Cloud via SCIM (from Microsoft Entra ID, Okta, or Google Workspace):
Only direct members of a group pushed to Atlassian Cloud are recognized.
If User Bob is a member of sub-team-alpha , and sub-team-alpha is nested inside jira-software-users within Active Directory, Jira Cloud will not see Bob as a member of jira-software-users .
As a result, Bob will be denied product access and will not receive a Jira license upon login.
Remediation Strategies for Enterprise Admins
Flatten Groups in the IdP: Before pushing groups through SCIM, configure dynamic group rules or flat distribution groups in the Identity Provider so users are direct members of the target group.
Use IdP Dynamic Membership: In Microsoft Entra ID or Okta, define dynamic user query rules (e.g., user.department -eq "Engineering" ) to populate the top-level SCIM-pushed group directly.
Sync Functional Groups and Map to Roles: Push functional flat groups (e.g., dept-finance , dept-security ) via SCIM, and assign those groups to Project Roles inside specific Jira projects.
Deep Dive: Project Roles Across System Schemes
Project Roles are not limited to Permission Schemes. A robust Jira architecture leverages roles across multiple system schemes to maximize reusability:
Notification Schemes:
Rather than notifying individual email addresses or hardcoded groups, configure notifications for events (e.g., Issue Resolved , Issue Commented ) to target Project Role: Developers or Project Role: Testers .
This prevents notification spam, ensuring only active team members in that specific project receive automated alerts.
Workflow Transition Conditions & Validators:
Workflow transition rules can restrict actions to specific roles. For example, a transition from In Review to Approved can enforce a condition: User must belong to Project Role: Approvers .
By using a role, 50 different projects can use the exact same workflow , while each project lead independently decides who holds the "Approvers" role in their project!
Issue Security Schemes:
Issue security levels (used to restrict sensitive tickets like HR inquiries or security vulnerabilities) should be granted to Project Roles (e.g., Security Champions ). Project Leads can add relevant internal staff to that security level without requesting a new security scheme from IT.
Team-Managed Projects: Access Levels and Roles Instead of Schemes
Blueprint 1.4 asks you to distinguish access in team-managed projects from permission schemes in company-managed projects . Team-managed projects have no permission scheme. Access is set in Project settings > Access with two controls:
- Access Level Who Gets In Automatically What They Can Do
- Open Everyone on the Jira site gets the Member role View, create, and edit issues
- Limited Everyone on the Jira site gets the Viewer role View and comment, but not create or edit
- Private Only Jira admins and people the project admin adds Whatever role they're given
Team-managed projects come with three default roles: Administrator , Member , and Viewer . You can't edit the default roles, but a project admin can duplicate one to create a custom role with a chosen set of permissions. Everyone added to a team-managed project automatically gets the basic permissions to browse the project and view its issues.
Exam angle: If a scenario says "anyone on the site can see and comment but not edit" in a team-managed project, the answer is the Limited access level. The company-managed equivalent is granting Browse Projects and Add Comments broadly in the permission scheme, but not Create Issues or Edit Issues.