You open a Jira issue and discover three related tickets pointing in different directions. One blocks another, a third duplicates an older request, and a fourth has no clear relationship at all.
That confusion slows triage, hides dependencies, and makes sprint planning harder. When teams add vague comments instead of meaningful relationships, important work can remain invisible until a deadline is close.
But here's the truth: issue links in Jira can turn scattered tickets into a clear work map. You can show dependencies, duplicates, risks, and related tasks in seconds.
This guide explains what Jira issue links mean, how to create them, which link types to choose, and how to keep your project relationships useful.
What Are Issue Links in Jira?
Issue links in Jira are relationships that connect one Jira issue to another. They show how tickets relate, such as one issue blocking another, duplicating another, or relating to another task.
A link adds context without combining separate tickets. Each issue keeps its own status, assignee, priority, and history while showing the connected work.
How Jira Links Two Issues
Jira usually displays a link with two directional descriptions. For example, one ticket may say blocks PROJ-104, while the other says is blocked by PROJ-103.
The relationship works in both directions. You can open either issue and understand the connection from that issue's perspective.
| Link relationship | Meaning | Practical example |
|---|---|---|
| blocks / is blocked by | One issue prevents progress on another. | An API change blocks a mobile app update. |
| duplicates / is duplicated by | Two issues describe the same work or defect. | Two customers report the same checkout error. |
| relates to | Issues connect without a dependency. | A research task relates to a future product improvement. |
| clones / is cloned by | One issue copies the purpose or structure of another. | A recurring regional rollout follows an earlier rollout ticket. |
Why Relationships Matter
A clear link helps you answer practical questions quickly. You can see what must happen first, which ticket contains repeated work, and where a change may create risk.
For example, a developer reviewing a login defect can spot the linked security review before changing authentication logic. That connection may prevent rework later.
How to Link Issues in Jira
You can create a relationship directly inside a Jira issue. The exact button label may vary slightly between Jira Cloud and Jira Server or Data Center.
- Open the first issue. Navigate to the ticket that needs a relationship.
- Find the issue actions menu. Select the three-dot menu or the More option.
- Choose “Link.” Jira opens a dialog for creating an issue relationship.
- Select the link type. Choose a clear relationship such as blocks, duplicates, or relates to.
-
Enter the other issue. Type its issue key, such as
APP-248, or search by its summary. - Add a short explanation. Explain the reason when the relationship may be unclear later.
- Save the link. Jira displays the relationship on the issue page.
Example: Linking a Dependency
Imagine you are managing a payment release. The mobile checkout ticket cannot finish until the payment service supports a new currency.
Open the mobile checkout issue and choose is blocked by. Then add the payment service ticket. Jira shows the dependency from both sides.
That relationship gives the delivery team a clearer sequence. The payment service work moves first, while the mobile ticket remains visible as dependent work.
Linking Issues During Creation
Some Jira configurations let you add a relationship while creating a ticket. Look for an Issue Links field or a related issue option in the creation screen.
This approach works well during bug triage. You can create a new defect and immediately connect it to the original customer report or affected feature.
Adding Links Through Bulk Actions
Jira administrators may enable bulk changes for selected issues. This can help when several tickets share a relationship, such as tasks connected to one larger initiative.
Use bulk linking carefully. A wrong relationship across many tickets can create confusion quickly. Review the selected issues before confirming the action.
Choosing the Right Jira Link Type
The link type should describe the relationship precisely. A vague connection creates less value than a useful one.
Use “Blocks” for Real Dependencies
Choose blocks when one issue must progress before another issue can move forward.
Example: a database migration blocks a release deployment. The deployment may still have other work, but the migration remains a meaningful dependency.
Do not use blocks simply because two tickets belong to the same feature. Shared ownership does not always mean one ticket prevents progress on the other.
Use “Duplicates” for Repeated Work
Use duplicates when two tickets describe the same defect, request, or task. Keep the stronger ticket active and close the duplicate with a clear explanation.
For example, three people may report that a search filter disappears after refreshing a page. Link the reports as duplicates instead of asking separate teams to investigate the same behavior.
Use “Relates To” for Useful Context
Relates to fits when issues share context without a direct dependency. This relationship works for connected research, design, maintenance, and planning work.
For example, a customer interview ticket may relate to a product discovery task. Neither ticket blocks the other, yet the connection helps future reviewers.
Use “Clones” for Repeated Issue Patterns
A cloned issue usually represents similar work created from an earlier ticket. Teams may use this relationship for repeated launches, regional configurations, or recurring operational tasks.
Check your team’s conventions before choosing this type. Some teams use clones for copied work, while others prefer a parent-child structure or templates.
Custom Link Types
Jira administrators can create custom relationships for specialized workflows. Examples include causes, caused by, implements, or tested by.
Custom types can improve clarity in complex projects. They can also create inconsistency when their meanings are unclear, so publish a short team guide.
Issue Links, Subtasks, and Parent Relationships
Jira offers several ways to connect work. Choosing the right structure keeps your project easier to read and report on.
| Connection method | Best use | Example |
|---|---|---|
| Issue link | Connecting separate issues. | A bug blocks a release task. |
| Subtask | Breaking one issue into smaller pieces. | A feature includes design, development, and testing subtasks. |
| Parent relationship | Grouping larger work across several tickets. | An epic contains multiple stories. |
| Remote link | Connecting Jira work to an external system. | A ticket points to a related page in another platform. |
When an Issue Link Fits Better
Use an issue link when both tickets should remain independent. They may belong to different teams, releases, or workflows.
For example, a legal review and a software defect may be connected. Making one a subtask of the other could create an inaccurate hierarchy.
When a Subtask Makes More Sense
Create a subtask when the work belongs directly inside a larger issue. Subtasks usually share the parent’s broader purpose and help one team divide execution.
A website redesign story may contain subtasks for accessibility checks, responsive testing, and analytics validation.
When to Use a Parent or Epic
Use a parent issue or epic when you need to group a larger body of work. This structure helps with planning, progress tracking, and reporting.
Issue links can still connect related work outside that hierarchy. For example, an epic may contain a feature while linking to a separate infrastructure dependency.
Practical Standards for Clean Issue Relationships
Good linking depends on consistent decisions. A relationship should help someone understand the work without asking the original creator for an explanation.
Write a Reason When Context Matters
The link type may explain the relationship, but a short comment can explain the reason.
Instead of linking two tickets without context, write: “The mobile release requires the new payment token before testing can begin.” That sentence remains useful during handoffs.
Link the Smallest Useful Set
Too many relationships make an issue difficult to scan. Link tickets that affect planning, execution, risk, or ownership.
A design ticket may connect to the implementation task and accessibility review. It probably does not need links to every discussion about the same product area.
Review Links During Triage
Set aside time during backlog review to remove duplicates, correct inaccurate relationships, and close obsolete connections.
A monthly review can reveal stale blockers. For example, a ticket may still show a dependency even though the required work finished two releases ago.
Use Consistent Direction
Choose the link direction that makes sense from the issue you are editing. Jira creates the reverse description automatically on the connected ticket.
If a release ticket cannot proceed because of an infrastructure task, use is blocked by from the release ticket. That wording makes the current risk obvious.
Protect Sensitive Relationships
Issue links can expose project names, risk details, or operational priorities to people who can view the connected tickets.
Check project permissions before linking restricted work. If a relationship reveals sensitive information, ask an administrator about the safest workflow.
Using ONES.com for Connected Project Work
ONES.com is a project management platform that can help teams organize connected work across planning, delivery, and collaboration.
If your team needs more than basic ticket relationships, a broader workspace may reduce the need to switch between separate project tools.
Useful ONES.com Capabilities
- Issue and task management: Create, assign, prioritize, and track work through configurable workflows.
- Relationship tracking: Connect related tasks and show dependencies across project work.
- Agile planning: Organize backlogs, sprints, stories, and development activities in one workspace.
- Roadmap planning: Connect strategic goals with planned initiatives and delivery milestones.
- Workflow customization: Adapt statuses, fields, permissions, and approval steps to fit team processes.
- Cross-team visibility: Give different departments a shared view of progress, ownership, and blockers.
- Reporting: Monitor progress, workload, risks, and delivery trends through project reports.
- Knowledge collaboration: Keep planning context and project discussions close to the work they explain.
For example, a product team could connect a customer request, development task, test activity, and release milestone within one broader workflow.
Jira remains a strong choice for many software teams. ONES.com may appeal when you want project planning and delivery coordination in a more unified environment.
Common Challenges
Challenge: Teams Use “Relates To” for Everything
Problem: The relationship list becomes crowded, while genuine blockers remain hard to spot.
Solution: Reserve relates to for useful context. Use dependency links when one ticket genuinely affects the timing or completion of another.
Challenge: A Link Points to the Wrong Ticket
Problem: Similar summaries make it easy to connect the wrong issue, especially in large projects.
Solution: Confirm the issue key, project name, summary, and status before saving. Add a brief reason when the relationship could be misunderstood.
Challenge: Old Blockers Stay Open
Problem: Teams trust the visible link and assume a dependency still exists.
Solution: Review blockers during sprint planning and release readiness checks. Remove or update links when requirements change.
Challenge: Duplicate Tickets Remain Active
Problem: Several people may investigate the same defect, producing repeated work and conflicting updates.
Solution: Select one primary issue, link the others as duplicates, and explain which ticket should continue.
Challenge: Permissions Hide Connected Work
Problem: A link may lead to an issue that some team members cannot view.
Solution: Review project access before relying on cross-project relationships. Use a visible summary or approved communication channel when appropriate.
FAQs
Can I link issues across different Jira projects?
Yes, you can often link issues across Jira projects when your permissions allow access to both tickets. Cross-project links are useful for dependencies between teams, such as an infrastructure task blocking a product release. Confirm that the relationship does not expose restricted details. Project administrators can control who creates, views, or edits connected work.
What is the difference between linking and making a subtask?
An issue link connects two independent tickets. A subtask belongs directly beneath a parent issue and usually supports that parent’s completion. Link a separate security review to a feature when both need independent tracking. Create a subtask when the review is one execution step inside the feature.
Can I remove an issue link in Jira?
Usually, yes. Open the issue, find the linked issues section, and select the remove or unlink action beside the relationship. You may need suitable permissions. Remove a link when it is inaccurate, obsolete, or replaced by a clearer relationship. Consider adding a short comment if the change affects active planning.
Should I use “blocks” when two issues are related to the same release?
No. A shared release does not automatically create a dependency. Use blocks only when one issue must progress before another can proceed. If both tickets simply support the same release, use relates to or group them under the appropriate epic.
Can Jira automation create issue links?
Jira automation can create or update relationships when your rules and permissions support that action. For example, a rule may connect a newly created defect to a recurring operational ticket. Test automation with a small project first. Incorrect rules can create many misleading relationships in a short time.
Conclusion
Issue relationships help you turn separate Jira tickets into a clearer picture of project work. The key is choosing a link type that accurately describes the connection.
Use blocks for dependencies, duplicates for repeated work, and relates to for useful context. Keep explanations short, review old connections, and choose subtasks or parent structures when they fit better.
But here's the practical takeaway: a small linking habit can prevent major planning confusion. When your team connects the right tickets, risks become visible earlier and handoffs become easier.
Top comments (0)