Study guide
4.3 Project Components, Component Leads & Default Assignees
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
4.3 Project Components, Component Leads & Default Assignees
Key Takeaways Explain This Topic AI
Components represent modular subsystems or functional areas within a single project, enabling issue grouping, subsystem triage, and granular reporting.
Each component can designate a Component Lead and specify a Default Assignee: Project Default, Project Lead, Component Lead, or Unassigned.
When an issue is created with multiple components that designate conflicting default assignees, Jira resolves the assignment alphabetically based on the component names.
Configuring a component's default assignee to 'Unassigned' requires that the global Jira setting 'Allow unassigned issues' is enabled.
Creating, editing, or deleting components requires the 'Administer Projects' project permission; designated Component Leads must possess the 'Assignable User' permission.
Last updated: September 2026
Project Components, Component Leads & Default Assignees
Within complex engineering and business initiatives, a single Jira project often encompasses multiple distinct disciplines, architectural layers, or functional subsystems. Rather than fracturing work across dozens of micro-projects—which complicates cross-team visibility and portfolio reporting—Jira provides Project Components . Components allow teams to subdivide a project into logical categories, automate issue routing to technical leads, and generate targeted subsystem metrics.
Architecture of Project Components
A Component is a project-level organizational construct managed under Project settings > Components . Unlike Project Categories (which group multiple projects globally) or Issue Types (which classify the nature of the work), Components represent what technical or operational subsystem the issue affects .
Typical Component Taxonomies
Software Engineering : Frontend , Backend API , Database , Authentication , Billing Engine , Infrastructure / DevOps .
IT Service Management : Hardware , VPN & Network , Email Services , Identity Management , Mobile Devices .
Business Operations : Legal Review , Vendor Procurement , Brand Assets , Copywriting .
Component Characteristics
Project-Scoped : By default, components exist strictly within the boundary of a single project. Two projects can each have a component named Database , but they are completely independent entities with distinct IDs.
Multi-Valued Field : The system field Component/s is multi-select. An issue can have zero, one, or multiple components assigned simultaneously.
Searchable in JQL : Components are fully queryable using standard JQL operators: /* Search for open issues in the Billing or API subsystems */
project = 'PAY' AND component in ('Billing Engine', 'Backend API') AND resolution is EMPTY
- /* Identify triage defects with no assigned component */
- project = 'PAY' AND issuetype = Bug AND component is EMPTY
- Component Leads & Default Assignee Configurations
One of the most powerful administrative features of components is their ability to automate issue triage by dynamically assigning incoming issues to designated domain experts.
Each component record contains four configurable properties:
Component Name : Unique text identifier within the project (e.g., Security ).
Description : Informational text outlining the scope of the component.
Component Lead : A specific user account designated as the technical or functional owner of the subsystem.
Default Assignee : A routing rule dictating who receives issues tagged with this component upon creation. DEFAULT ASSIGNEE CONFIGURATION OPTIONS
- ┌──────────────────┐
- │ Project Default │ ──▶ Assigns to the project-wide default (Project Lead or Unassigned)
- └──────────────────┘
- ┌──────────────────┐
- │ Project Lead │ ──▶ Assigns directly to the user designated as Project Lead
- └──────────────────┘
- ┌──────────────────┐
- │ Component Lead │ ──▶ Assigns to the user designated as the Component Lead
- └──────────────────┘
- ┌──────────────────┐
- │ Unassigned │ ──▶ Leaves issue unassigned (Requires global 'Allow unassigned issues')
- └──────────────────┘
- The 4 Default Assignee Modes
Default Assignee Setting Operational Behavior Technical Prerequisites & Fallback
Project default The issue gets the project's own default assignee from Project settings > Details . The project default can only be the project lead or Unassigned.
Project lead (shown as space owner) The issue is assigned to the project lead. The lead must be assignable in the project.
Component lead The issue is assigned to the component's lead. Set a component lead first, and make sure that person is assignable.
Unassigned The issue is created with an empty Assignee field, which suits open triage queues. Available only if the site allows unassigned issues ( Allow unassigned issues in Settings > System > General configuration ).
Atlassian's rule for combining the two levels is simple: a component's default assignee overrides the project's default assignee. The project default only applies when no component is selected, or when the component itself is set to Project default .
Note
Jira Cloud also supports Compass components , which link issues to software components in Atlassian Compass. The default-assignee behavior in this section applies to standard Jira components. Check which kind a project uses before troubleshooting.
Multi-Component Conflict Resolution Algorithm
Because the Component/s field is a multi-select field, users can select two, three, or more components when submitting an issue. What happens when an issue is created with multiple components that designate different, conflicting default assignees ?
Consider this real-world scenario:
Component 'Database' : Component Lead is Alice ; Default Assignee is Component Lead .
Component 'Authentication' : Component Lead is Bob ; Default Assignee is Component Lead .
Component 'UI' : Component Lead is Charlie ; Default Assignee is Component Lead .
A developer creates an issue via the Create Issue modal, leaves the Assignee field set to Automatic , and selects both 'Database' and 'Authentication' .
Jira's Alphabetical Rule
Atlassian documents the rule directly: if an issue is created with more than one component and those components have different default assignees, Jira assigns the issue to the default assignee of the component whose name is first alphabetically. MULTI-COMPONENT RESOLUTION FLOWCHART
- Issue Created with Multiple Components
- ['Database' (Alice), 'Authentication' (Bob)]
- │
- ▼
Does user have manual Assignee input?
- ├── YES ──▶ Assigns to manually selected user
- └── NO (Set to 'Automatic')
- │
- ▼
Sort selected components alphabetically:
- 1. 'Authentication' (Lead: Bob)
- 2. 'Database' (Lead: Alice)
- │
- ▼
Select FIRST component in alphabetical list:
- 'Authentication' has Default Assignee = Component Lead
- │
- ▼
- Issue Assigned to BOB
Jira looks at all components selected on the issue.
If their default assignees resolve to different people, Jira sorts the component names alphabetically (A to Z) .
The default assignee of the component whose name is first alphabetically is used.
In our scenario:
Comparing 'Authentication' vs 'Database' :
'Authentication' begins with A , which precedes D alphabetically.
Therefore, the issue is automatically assigned to Bob !
Important
Manual Selection Precedence : The component default assignee algorithm executes only when the Assignee field is left as Automatic on issue creation. If the user explicitly selects any specific user (or explicitly selects Unassigned ) in the Assignee dropdown on the Create screen, the user's manual selection always overrides component routing rules.
Administrative Permissions & Component Lifecycle Management
Managing components is a decentralized administrative function designed to be delegated to project managers and leads without requiring global site administrator rights.
Required Permissions for Component Administration
To create, edit, or delete components in a project, a user must hold the Administer Projects project permission within the project's active Permission Scheme.
Users with global Administer Jira permission can also manage components in any project.
Holding the title of Component Lead does not inherently confer administrative rights over the project. A Component Lead who lacks Administer Projects cannot edit component descriptions, change default assignees, or create new components.
Component Deletion Safeguards
When an administrator deletes a component from Project settings > Components , Jira enforces data integrity protection through a deletion modal dialog:
Delete Component Dialog : Prompts the administrator with the question: 'What should happen to issues currently assigned to this component?'
Option 1 (Swap Component) : Move all issues to an alternative existing component selected from a dropdown list.
Option 2 (Remove Component) : Remove the deleted component from all issues, leaving the component field empty (or retaining any other components that were co-assigned).
Existing issues are never deleted or corrupted when a component is removed from a project.