4.3 Project Components, Component Leads & Default Assignees

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:

1. Component Name: Unique text identifier within the project (e.g., Security).
2. Description: Informational text outlining the scope of the component.
3. Component Lead: A specific user account designated as the technical or functional owner of the subsystem.
4. 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

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

1. Jira looks at all components selected on the issue.
2. If their default assignees resolve to different people, Jira sorts the component names alphabetically (A to Z).
3. 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.