Here's how a plan usually falls apart. Nothing looks wrong anywhere. The work item is in progress, the assignee is busy, the board is green. Two other teams are waiting on that item, and you don't notice until the meeting where someone has to explain a missed date.
Jira does support dependencies. It just doesn't put them in front of you. The main challenge isn't recording them, but it's making them visible enough that people act, and that's what most Atlassian Community threads on the subject come down to. This article covers both halves: what Jira gives you, and what you have to do yourself.
The short version:
- Dependencies in Jira are work item links, and only blocks / is blocked by counts for scheduling.
- The project timeline shows them inside one project. Cross-project needs Plans (Premium) or an app.
- Nothing reschedules itself when a blocker slips, apart from the auto-scheduler in Plans, and that one has rules of its own.
- The practices in the second half matter more than whichever view you pick.
New to this? Start with section 1 and skip the rest until you've settled on a link type.
1. Jira dependencies are just links
Every Jira user already knows how to do this: open a work item, select the Link button, pick a relationship, pick the other item.
The four default link types:
Link type | What it means | Counts as a dependency? |
|---|
blocks / is blocked by | This has to finish first | Yes — use this one |
relates to | Related, unspecified | No |
duplicates | Same work recorded twice | No |
clones | Copy of another item | No |
Admins can add more types, and a number of teams do.
Why this matters: timelines only draw specific link types. If half your team records blockers as "relates to", those dependencies are in your data and on zero charts. Most "why aren't my dependencies visible?" questions have the same answer.
Three things to settle before anything else:
- Pick one link type for scheduling dependencies and write it down where people will read it.
- Ask an admin to enable work item linking globally — nothing works until that's on.
- Note that link types are global, not per project, so you can't fix this for one team without affecting everyone.
2. Where you can see dependencies in Jira, and where you can't
Inside the work item
Linked items are displayed as a list in the details. Helpful for "what's holding this one up?", useless for planning, because you see one step of the chain and never its shape.
On the project timeline
Dependencies become lines between bars. What you get:
- Lines drawn from the Blocks link type only.
- Work items from a single project only.
- A red line when dates overlap so a blocked item would start before its blocker finishes.
- A detail view when you select a line, which also shows dependencies between child work items even when their parent is collapsed.
In Plans (Premium)
Plans is the only native place where dependencies cross project boundaries. What you get:
- Dependencies pulled from the links you already have, across multiple projects.
- Dependent items shown either as connecting lines or as numbered badges at the ends of the bars, which turn red when the lead-in item puts the second one at risk.
- A Dependencies view — a Jira dependency map laying everything out as a network instead of arrows on a schedule.
- A Program board for programme-level planning conversations.
Four things catch people out here, and all four look like bugs until you know about them:
- Both linked items have to sit inside the plan's sources, or the line won't appear at all.
- Dependencies need dates on both ends. No start and due date, no bar. No bar, no line. Which date fields drive the bars is configurable, so decide once whether it's start/due or target start/end and stay consistent; otherwise two plans mean different things by the same picture.
- Watch the 5,000-item cap. A plan pulls work from its sources up to a limit, and past that you're missing items without being told. If a plan feels like it's hiding dependencies, check the item count in its issue sources before blaming the links.
- Drawing a line writes a Blocks link into Jira, and you can't pick a different type from inside the plan. Changes you make in a plan reach Jira only when you hit Save changes.
In JQL and the API
- linkedIssues() finds what's linked to a particular work item.
- There's no clean native filter for "everything blocked right now, across everything". Your options: add a Blocked flag or an issue status, build the view in Plans, or use an app.
- Need the data outside the UI? Export plan data as CSV, or use the REST API, where every link has its own dependency id. Useful when you're deleting stale links in bulk instead of clicking through them one at a time.
3. Setting up custom link types for Plans
Worth knowing before you invent your own link types: by default, Plans treats every work item link as if it were Blocks, meaning the first item has to end before the second can begin. If you want Plans to use a link type of your own, an admin has to set it up, and it's a two-step job.
Step 1 — create the link type
- Settings icon → Work items.
- In the sidebar, Work item linking under Work item features.
- Make sure linking is ON. If it isn't, select Activate.
- Add your link type under Add New Link Type with a name plus outward and inward descriptions, or edit an existing one.
Step 2 — tell Plans to use it
- Settings icon → Jira apps.
- Dependencies in the side nav.
- Add your link type from the dropdown, remove one with the x, or use Swap to invert which side is doing the blocking.
- Save changes.
Two notes people miss. These settings apply to every plan in your instance, not the one you're working on. And the same screen holds the sequential-or-concurrent choice: with sequential dependencies, two linked items scheduled into the same sprint are flagged as off-track, which is usually what you want for anything with a real hand-off.
4. The bit nobody warns you about
The line turns red, and nothing moves. If a blocker slips by a week, all the dependent tasks stay where you left them, and you won't see the impact on downstream dates until someone works it out by hand.
Three gaps worth naming so you don't spend an afternoon hunting for them:
- No cascade, with one exception. Jira won't reschedule dependent work on a project timeline, and most apps won't either, mine included. Plans has an auto-scheduler that takes dependencies into account, and its rules are worth knowing before you trust it: it skips items that are Done, ignores cyclical dependencies (A blocks B, B blocks A), won't touch work in an active sprint, and assumes one person per story-level item.
- Finish-to-start only. Start-to-start, finish-to-finish and lags aren't available.
- No critical path, no slack. You can see what's linked without seeing which chain decides your end date.
None of that makes Jira unworkable. It does mean your process has to carry weight the tool doesn't.
5. What happens after the line turns red
Say a blocker slips a week. Here's the part the arrows don't cover.
You open the timeline, and the picture is clear enough: the dependent story now starts before its blocker finishes, so the line is red. You have three moves, and they're the same three everywhere — stretch the story over more days, hand it to someone else, or cut scope.
So you stretch it. The daily load drops, the dates work again, and the red goes away. Then you find out two weeks later that the same person was already carrying a release and is off for four days in the middle of it. Yikes.
Or you reassign it, which fixes the chart instantly and puts a second person at 140% for a fortnight. Not ideal too.
Neither of those shows up on a dependency view, because a dependency view is about order, not about people. To answer "who absorbs this?", most teams open a second tool: Plans for the arrows, then a spreadsheet, a chat with the team lead, or a resourcing app for the human part. And because that's two screens, it usually happens once, during the escalation, rather than every time a date moves.
That's the gap the tool we work on is built around.
Group by person, and an arrow connects two people's weeks, not just two tickets. Workload is the detailed one — the same arrows over booked hours, with each person's schedule, holidays, and vacation taken out — so you see who goes red before you commit. Same Jira links throughout.
➡️ Try dependencies in Planyway
Two other things worth knowing, so you can judge whether it's relevant to you:
- No Premium needed for cross-project dependencies. Plans is the only native way to see links across projects, and it's an org-wide upgrade. Plenty of Marketplace apps solve that, ours among them.
- You can ask instead of looking. The Risk Agent in Rovo checks remaining work against real availability and answers questions like "which milestones are at risk?". It reasons about capacity rather than about dependency chains, so use it as a second opinion on a plan you've already read.
If your dependency problem is mostly about sequence, the native tools plus the habits in the next section will get you there. If it's mostly about who ends up carrying the slip, that's a different tool.
6. Practices that keep the data honest
Link at the same level. Epic to epic, story to story. Jira will happily let you link an initiative to a subtask, and the result is a plan nobody can read: one side is a quarter of work, the other is half a day. Pick the level you manage dependencies at — epic is the usual answer — and keep links there.
Let the blocked team create the link. They're the ones who care whether it's right. When the blocking team owns it, links get created during planning week and never touched again.
Say what you're waiting for, not only that you're waiting.
- Weak: Blocked.
- Useful: Blocked until the API returns customer IDs, needed by 14 March.
Provide a person and a date for every cross-team dependency. "Team B owns it" is how a dependency sits untouched for a month.
Let automation do the nagging. Links are easy to create and easy to forget, so two Jira Automation rules cover most of the pain. Both rely on Jira's ability to branch to linked work items:
- When a due date is changed → branch to the work items it blocks → comment with the new date and notify their assignees.
- When a blocker is resolved → comment on the blocked items, so the waiting team finds out that day instead of at the next stand-up.
Neither rule is clever. Both beat someone remembering.
Review on a schedule, not when something explodes. Five minutes in sprint planning or at a weekly delivery sync catches most of it. Watching the number of open cross-team dependencies over time tells you more about delivery risk than any single red line does.
Prune stale links. They're worse than no links, because red lines that turn out to be wrong train everyone to ignore the red lines that aren't.
Check permissions first. Jira link permissions apply everywhere, including inside apps. If someone can't create a link in Jira, they can't create one on a timeline either.
7. Roughly what you need, depending on where you are
One team, one project
Blocks links, the project timeline, a comment convention. That's it. Don't overbuild this.
A few teams, multiple projects, no Premium
The awkward middle. You need a cross-project timeline of some kind, and that's the gap apps fill — Planyway among them, which draws the same Jira links across projects on any plan, with dependencies as a toggle you can switch on in the timeline, the Gantt chart, or the workload view. Whatever you pick, expect the automation rules above to do more for you than the picture will.
Programme level, Premium
Use what you're already paying for: the dependency map, the warnings, the Program board and the auto-scheduler cover more ground than most teams realise. However, if you need capacity next to your dependencies, that's where a separate app still earns its place.
Whatever you settle on, the useful test is simple: when a date moves, does anyone downstream find out the same day? If the answer is no, that's the gap to fix first, whichever view you're using.
Quick links
Find more posts tagged #dependencies, #jira-cloud and #plans if you want to see how other teams have solved this.
Your turn
How does your team track dependencies? Strictly with Blocks links, or did you end up with a flag, an issue status, or a custom field doing the job?
And if dependencies went from invisible to managed on your team, what's the key thing that did it: a report, automation, or someone insisting on a weekly review?
If this article missed something your team does differently, say so in the comments — that's usually where the good answers live anyway :)
