How to Create & Manage Dependencies in Jira, Add Dependency in Issues, Tickets, Tasks Easily 2026

A dependency in Jira is a typed link between two issues that records an order-of-work relationship, not just a loose association. It doesn't move either issue's status automatically — it's informational, meant to tell anyone looking at the ticket that something else has to happen first, or that this ticket is itself in someone else's way. Setting these up consistently is what lets a team spot a stalled blocker before it quietly delays three other tickets.

Open any issue and scroll past Description and Child work items to the Related work items section. It starts with a 'Link similar work items' search that Jira runs automatically, plus a manual linking row below it — a link-type dropdown next to a 'Type, search or paste URL' field. This is the section that holds every dependency for the issue, and it's the same place you'll return to whenever you need to check or edit one.

Click the link-type dropdown and Jira shows the full list of relationship types available — is blocked by, blocks, and several non-dependency options like added to idea, merged into, and implements. Picking the wrong direction is the single most common dependency mistake: 'is blocked by' means this issue is waiting on the other one, while 'blocks' means this issue is what's holding the other one up. Read the sentence the dropdown forms with your issue before confirming — it should describe the real relationship in plain English.

Type into the search field and Jira surfaces matching issues from across your accessible projects as you type — in one example, searching from a ticket in the SC App V2 project returned matches like a support page ticket, a crash report, and a Play Store release ticket from a completely different project. Click the correct one from the list, then confirm the link. There's no need to know the exact issue key ahead of time; typing a few relevant words is usually enough to find it.

It's tempting to link everything that's loosely related, but a ticket buried under a dozen dependencies becomes unreadable and nobody trusts the list enough to check it. Link only genuine blocking relationships, and revisit them during sprint planning or backlog grooming rather than letting them silently pile up. If a dependency is resolved, don't leave the stale link sitting there — remove it so the remaining links stay meaningful.

Individual issue links tell you about one relationship at a time; the project's Timeline view shows the bigger picture. Under a board's Timeline tab, epics and releases are laid out against actual dates, so you can see at a glance whether a dependency chain fits inside the schedule or is quietly pushing a release date out. This view is where planning conversations about dependencies usually happen, since it turns a list of blocked tickets into a visual timeline stakeholders can actually read.