Linking Jira Issues: A Practical Guide to Better Workflows

Jira work can become confusing when related tasks sit apart. A bug may affect a feature, a story may depend on another team, and a duplicate ticket may attract unnecessary attention.

When those relationships stay hidden, people repeat investigations, miss dependencies, and close work too early. A simple status update rarely explains the full impact of a change.

Linking Jira issues gives your team that missing context. You can connect related work, show dependencies, identify duplicates, and make decisions with fewer interruptions.

This guide explains how issue links work, which relationship to choose, and how to build a cleaner workflow. You will also see practical examples, common mistakes, and a tool option for broader project coordination.

How to Link Jira Issues Correctly

Linking Jira issues means connecting two Jira tickets with a defined relationship, such as “blocks,” “is blocked by,” “duplicates,” or “relates to.” These links help teams understand how work affects other work.

Here is the basic process:

1. Open the Jira issue that needs a connection.
2. Choose the More actions menu or the Link option.
3. Select the relationship that accurately describes the connection.
4. Search for the related issue by its key, summary, or other available details.
5. Add a short explanation when the relationship needs extra context.
6. Save the link and confirm that both issues show the relationship correctly.

For example, connect a bug to the story it affects with is caused by or relates to, depending on your team’s workflow. Connect a release task to a blocking infrastructure task with is blocked by.

Here's why: the relationship label carries meaning. Linking two tickets alone creates a connection, while choosing the correct link type explains how the work fits together.

What Jira Issue Links Actually Show

Jira issue links create a visible relationship between separate pieces of work. They help you follow dependencies, discover duplicate requests, and connect technical work with business outcomes.

Each link usually has two directions. For example, one issue may say blocks, while the connected issue says is blocked by. Jira presents these labels from each issue’s perspective.

Common Jira Link Types

Link type	Use it when	Example
relates to	Two issues share useful context without a direct dependency.	A design question relates to a planned feature.
blocks	Progress on one issue prevents progress on another.	An API change blocks mobile testing.
is blocked by	An issue cannot move forward until another issue progresses.	A deployment task is blocked by security approval.
duplicates	Two issues describe the same problem or request.	A second report describes an existing login defect.
is duplicated by	Another issue repeats the current issue.	A new ticket is duplicated by an earlier support request.
clones	A nearly identical issue needs separate ownership or tracking.	A team creates a regional version of a standard rollout task.
is cloned by	Another issue was created as a copy of the current issue.	A testing task is cloned for another environment.

Dependency Links Need Extra Care

Use dependency links when one task genuinely affects another task’s progress. A shared topic does not automatically create a dependency.

Imagine a marketing page and a payment service both support the same launch. They may relate to each other, yet the page might continue without the payment work.

Calling that relationship blocks could delay the page unnecessarily. Choose relates to unless one task must wait for the other.

A Practical Workflow for Connecting Related Work

Good issue linking follows the way your team makes decisions. Start with the most important relationship, then add context that helps someone understand the connection later.

1. Identify the Relationship Before Opening Jira

Ask what connects the two issues. Is one dependent on the other? Do they describe the same problem? Are they simply part of the same initiative?

For example, consider these three situations:

• A database migration must finish before an application release. Use is blocked by.
• Two customers report the same checkout error. Use duplicates.
• A research task and a product story share useful background. Use relates to.

Choosing the relationship first prevents vague connections and reduces cleanup later.

2. Open the Issue That Needs More Context

Start with the ticket where another person would benefit most from seeing the relationship. This is often the blocked task, the customer-facing bug, or the central story.

Open the issue and locate its action menu. Jira layouts vary between projects and configurations, so the link command may appear under More, Actions, or a dedicated link control.

3. Select the Most Precise Link Type

Choose the label that describes the relationship in plain language. Avoid using relates to for every connection because it hides important workflow details.

Suppose a payment defect prevents release testing. The useful relationship is is blocked by. That label immediately tells the test owner why progress has stopped.

4. Find and Connect the Related Issue

Search using the issue key when you know it, such as PAY-184. You can also search by the issue summary if the key is unavailable.

Check the selected ticket before saving. Similar summaries can lead to accidental links, especially in large projects with repeated bug descriptions.

5. Add Context Where the Link Alone Is Insufficient

A link label explains the relationship, while a short comment can explain the reason. Use a comment when timing, scope, or ownership matters.

For example, write: “Release testing cannot begin until PAY-184 reaches the staging environment.” This gives the team a clear reason and a practical next step.

6. Verify the Relationship From Both Issues

After saving, open the connected ticket and confirm that Jira displays the opposite direction correctly. This quick check catches wrong selections and misleading labels.

Review important links during planning, refinement, and release preparation. Relationships can become outdated when scope changes.

When to Link Issues Instead of Creating More Tickets

Teams often create extra tickets when one issue needs more visibility. A link may provide enough context without splitting the work into several thin tickets.

Use a Link for Existing Work With a Clear Relationship

Create a link when both issues have separate owners, statuses, or delivery paths. Each ticket remains independently trackable while the connection stays visible.

For example, a product story and a compliance review may need separate owners. Linking them shows the relationship without forcing both teams into one workflow.

Create a New Issue When the Work Has Its Own Outcome

A separate issue makes sense when the work needs its own acceptance criteria, estimate, owner, or lifecycle.

A comment about accessibility may be enough for a small adjustment. A full accessibility audit deserves its own issue, especially when several findings require separate action.

Use Parent and Child Structures for Scope

Issue links describe relationships between tickets. Parent and child structures describe hierarchy, such as an epic containing stories or a task containing subtasks.

Use hierarchy for work that belongs inside a larger deliverable. Use links for dependencies, duplicates, and relationships crossing that hierarchy.

The best part? Combining both gives you a clearer picture. An epic can contain delivery work, while links show risks involving another project or team.

Examples of Linking Jira Issues in Real Workflows

Different teams use issue relationships in different ways. The right link depends on the decision someone needs to make after reading the ticket.

Software Development Example

A developer discovers that a new authentication change affects an existing login bug. The developer links the bug and story with a relationship that shows the connection.

If the story caused the defect, the team can use is caused by where that link type exists. If the connection is still under investigation, relates to is safer.

Release Management Example

A release ticket depends on infrastructure configuration, security approval, and test completion. The release ticket can link to each prerequisite.

Use is blocked by for work that must finish first. Add a comment identifying the required environment or approval stage.

This setup helps a release manager focus on genuine blockers instead of scanning every open ticket manually.

Support and Product Example

A support team receives three reports describing the same checkout problem. One ticket becomes the primary investigation, while the others receive duplicates links.

Keep customer details in the appropriate ticket fields and comments. The relationship lets the product team see the wider impact without maintaining separate investigations.

Cross-Team Planning Example

A mobile team needs an endpoint change from the platform team. The mobile story links to the platform task as is blocked by.

When the platform task moves forward, the mobile team can update its plan. The connection also gives managers a clearer view of cross-team risk.

Using ONES.com for Connected Project Work

ONES.com provides a broader workspace for teams that need connected planning, issue tracking, collaboration, and delivery visibility. It can help when relationships extend beyond a single Jira project.

Consider it when your team manages product work, technical requests, approvals, and team coordination across several workflows.

Capabilities That Support Connected Work

• Project and issue tracking: Organize tasks, defects, requests, and milestones in structured workspaces.
• Custom workflows: Adapt statuses, transitions, and approval stages to match how your team operates.
• Dependency visibility: Show blocked work and relationships that affect delivery timing.
• Cross-team planning: Coordinate responsibilities across engineering, product, support, and operations.
• Task ownership: Assign accountable people and clarify who handles the next action.
• Comments and collaboration: Keep decisions and follow-up conversations beside the related work.
• Dashboards and reporting: Monitor progress, risks, workload, and delivery trends in one workspace.
• Permission controls: Manage access across teams, projects, and sensitive work areas.
• Roadmap planning: Connect high-level initiatives with the tasks required to deliver them.

For example, a product launch may involve engineering tasks, content approvals, customer support preparation, and regional coordination. A connected workspace can keep those relationships visible across the full launch plan.

You might be wondering: should you move every Jira relationship into another platform? Start with the workflow problem. If Jira already provides the visibility you need, improve your linking habits first.

Rules for Cleaner Issue Relationships

Issue linking works best when your team follows a shared standard. A short agreement can prevent inconsistent labels and confusing ticket histories.

Use Specific Links for Dependencies

Reserve blocks and is blocked by for genuine delivery constraints. If a task only shares a topic, choose relates to.

This distinction matters during sprint planning. A false blocker can make a team delay useful work, while a missing blocker can create an avoidable surprise.

Link the Primary Issue to Duplicates

When two tickets describe the same problem, decide which one remains active. Link the other ticket as a duplicate and add a short explanation.

Keep the primary ticket easy to find. Include the affected area, current investigation, and next action in its summary or description.

Explain Unusual Relationships

Some connections are obvious. Others need context because the relationship may seem unclear several weeks later.

A short comment such as “Both tickets depend on the same tax calculation change” can save a future investigation.

Review Links During Planning and Closure

Check linked work before starting a sprint, approving a release, or closing a major ticket. Status changes can make old relationships inaccurate.

If a blocker no longer applies, remove or update the link. Cluttered relationships make important risks harder to notice.

Keep Link Types Consistent Across Teams

Agree on how your organization uses terms such as relates to, blocks, and duplicates. Different interpretations create misleading reports and planning conversations.

Publish the agreement where team members can find it quickly. A short internal guide with three examples may be enough.

Common Challenges

Challenge: The Link Option Is Missing

Problem: Your Jira screen does not show a link command.

Solution: Ask a Jira administrator to check permissions, screen configuration, and available link types. Your project setup may hide the action from certain roles.

Challenge: Too Many Issues Look Similar

Problem: Search results show several tickets with nearly identical summaries.

Solution: Compare project keys, status, assignee, and recent activity before selecting an issue. Open the candidate ticket when uncertainty remains.

Challenge: Teams Use Different Link Meanings

Problem: One team uses relates to for dependencies, while another reserves it for general context.

Solution: Create a shared linking policy. Define each relationship with one short example and review it during team onboarding.

Challenge: Linked Work Becomes Outdated

Problem: A ticket still shows a blocker after the dependency was removed.

Solution: Review relationships at major milestones. Remove links that no longer explain current work, and add a comment when the change affects planning.

Challenge: Links Replace Useful Explanations

Problem: A relationship exists, yet nobody understands why it matters.

Solution: Add a concise comment describing the business impact, timing, or next action. Keep the explanation specific and easy to scan.

FAQs

Can I link issues across different Jira projects?

Yes, Jira can support links across projects when your permissions and project configuration allow it. Open the issue, choose the linking action, and search for the related ticket using its project key. Cross-project relationships are useful for shared services, release dependencies, and support escalations. Check the connected issue afterward to confirm both sides display the relationship correctly.

What is the difference between linking and creating a subtask?

A subtask belongs under a parent issue and represents a smaller piece of that parent’s work. A linked issue remains separate and can have its own owner, status, sprint, or delivery path. Use subtasks for work inside one outcome. Use links when two independent tickets have a dependency, duplicate relationship, or shared context.

Should I use “relates to” for every connection?

Use relates to when two issues share useful context without a direct dependency. Avoid using it when one issue blocks progress or duplicates another. Specific labels help during planning because they show urgency and impact. If you are unsure whether a dependency exists, use relates to temporarily and clarify the relationship after investigation.

Can I link an issue to another issue after work has started?

Yes. You can add relationships whenever new information reveals a dependency, duplicate, or shared impact. Late linking is valuable when requirements change or an investigation uncovers connected work. Add a short comment explaining why you created the link. That context helps teammates understand the timing and prevents confusion during review.

How many links should one Jira issue have?

There is no useful universal number. Add every relationship that helps someone make a decision, then remove connections that no longer matter. An issue with dozens of vague links creates noise. An issue with several precise relationships can improve planning. Review the links during refinement, release preparation, and major scope changes.

Conclusion

Disconnected Jira tickets make dependencies harder to see, duplicate work easier to create, and releases more difficult to coordinate.

Linking related issues gives your team practical context. Choose precise relationship types, explain unusual connections, and review links as work changes.

Start with one active project. Link genuine blockers, identify duplicate tickets, and connect related work that crosses team boundaries. Then create a shared standard for everyone.

But here's the truth: issue linking only helps when the relationships stay accurate. A few meaningful connections can improve your workflow more than a large collection of vague links.