Short definition
Linked issues in Jira are explicit relationships between two issues, expressed as a typed link such as 'blocks,' 'is blocked by,' 'relates to,' 'duplicates,' or 'is cloned by.' Unlike the parent/child sub-task relationship, links are bidirectional, work across projects, and form a graph rather than a tree. Admins can define custom link types under Issue Linking.
When to link vs. when to nest
The decision hinges on whether the relationship is part-of or related-to:
- Part-of: a sub-task. The work doesn’t make sense without the parent. The QA sub-task of a story can’t exist without the story.
- Related-to: a link. The two issues make sense independently but one affects the other. “INFRA-42 blocks PROJ-101” means PROJ-101 can’t be done until INFRA-42 is, but both are real deliverables in their own right.
This distinction matters because sub-tasks are project-locked and limited to one parent. Cross-team dependencies, where the dependency lives in a different project entirely, must be expressed as links.
Common link patterns
- Blocks / is blocked by - dependency tracking. Used heavily in release planning: a release version is ready when nothing in it is blocked by an open issue.
- Duplicates / is duplicated by - de-duplication on triage. The duplicate gets resolved as Duplicate; the original gets the customer detail.
- Relates to - weak association. Useful for “if you change this, also look at that,” but easy to overuse.
- Caused by - incident postmortems link the incident to the change request or release that caused it.
- Implements (custom) - many teams add this to link engineering work to design specs or RFCs.
Querying the link graph
linkedIssues() is the JQL function for traversing links one hop. There’s no native multi-hop function, so
queries like “everything transitively blocking this release” usually require a Jira app or repeated
expansions in a dashboard. Reports that visualise the link graph (e.g. dependency maps in Advanced Roadmaps)
do the expansion under the hood.
Links and clones
The “Clone” action on an issue creates a new copy and auto-adds an “is cloned by” / “clones” link between the two. The link is informational - it records provenance but doesn’t keep the two issues in sync. If the clone is meant to inherit attachments and comments too, an admin can configure which fields and content the Clone action copies under Issue Linking settings.
Common questions
What are linked issues in Jira?
Linked issues are explicit relationships between two issues, expressed as a typed link such as 'blocks,' 'is blocked by,' 'relates to,' 'duplicates,' or 'is cloned by.' Unlike the parent/child sub-task relationship, links are bidirectional, work across projects, and form a graph rather than a tree.
What's the difference between linking and sub-tasks?
A sub-task has exactly one parent in the same project. A linked issue can have many relationships to issues in any project. Sub-tasks form a hierarchy; links form a graph. Use sub-tasks for phase decomposition of one deliverable, links for dependencies between deliverables.
What are the default Jira link types?
Out of the box: blocks / is blocked by, clones / is cloned by, duplicates / is duplicated by, relates to (bidirectional), and on Jira Software, causes / is caused by. Admins can add custom link types under Settings -> Issues -> Issue linking.
Can JQL query linked issues?
Yes. `issue in linkedIssues(ABC-1)` returns every issue linked to ABC-1. `issue in linkedIssues(ABC-1, 'blocks')` filters by link type. This is how dashboards built for release readiness or dependency tracking surface blockers - they query the link graph rather than the project tree.