Short definition
A component in Jira is a project-level tag that groups issues by the part of the product they affect - e.g., 'checkout-service', 'mobile-app', 'billing-api'. Components can have a default assignee and a component lead, which Jira uses to automatically route new issues. Components are defined per-project and don't cross project boundaries by default.
How components route work
Each component can have a component lead and a default assignee policy. The policy choices are:
- Project default - whatever the project’s default assignee is.
- Component lead - the configured lead for this component.
- Project lead - the project’s lead.
- Unassigned - explicitly leave unassigned.
When a new issue is created with the Components field set, Jira applies the routing policy of the chosen component. This is one of the easiest pieces of automation in Jira and a quick win for teams that route bugs by service: tag the service as a component, set the team’s tech lead as the component lead, set the component’s default-assignee policy to “Component lead.” Every new bug filed against that service auto- assigns to the right person.
Components vs. labels vs. custom fields
Three near-synonyms in Jira:
- Components - admin-defined, controlled vocabulary, routing-aware, project-scoped.
- Labels - free-form, no control, global, no routing.
- Custom field (single-select) - admin-defined, controlled vocabulary, no routing, scoped to the contexts the field is in.
Components win when routing matters and the values change slowly. Labels win when the values are noisy and short-lived (campaign tags, postmortem tags). Custom fields win when the field needs to be required, must have specific options, or needs to span issue types in complicated ways.
Components and versions on release dashboards
Component is a primary slicing dimension on Jira’s release dashboards. Filtering “What’s in version 4.12.0
for the checkout-service component?” is a common release-readiness query. JQL: fixVersion = "4.12.0" AND component = "checkout-service".
Cross-project components
Components don’t cross projects. Two different projects with the same component name are separate component objects with separate routing rules. For organisations that genuinely need a shared component taxonomy, a single-select custom field with shared options is usually a cleaner answer than synchronising components across projects.
Common questions
What is a component in Jira?
A component is a project-level tag that groups issues by the part of the product they affect - e.g., 'checkout-service', 'mobile-app', 'billing-api'. Components can have a default assignee and a component lead, which Jira uses to automatically route new issues. Components are defined per-project and don't cross project boundaries by default.
What's the difference between a component and a label?
Components are admin-defined and project-scoped; labels are free-form and global. Use components when the set of values is controlled and short-lived issues need to be routed to a specific team or owner. Use labels for ad-hoc tagging where any reporter can invent a new value.
Can an issue have multiple components in Jira?
Yes. The Component/s field is multi-select - an issue can be tagged with as many components as apply. If two components both have default assignees, Jira applies the first one alphabetically; this is rarely the desired behaviour, so most teams set explicit assignees rather than relying on multi-component routing.
Should we use components or sub-projects for team ownership?
Components are lightweight and fast to set up; sub-projects (or separate projects per team) are heavier but give independent backlogs, boards, and permission models. Use components when teams share a backlog and just need to slice it by ownership. Use separate projects when teams need genuinely independent processes.