Cross-board dependencies
Last updated: 1 September 2026
Jira stores blocking relationships on the issue, and shows them one issue at a time. Kanban+ reads the same links and draws the picture they add up to: what's stuck, what's holding it up, which chain determines your finish date, and which of your blockers live on someone else's board.
Everything here is built on real Jira issue links. Kanban+ creates none of its own — when you add a blocker from the Timeline, it writes an actual Jira "Blocks" link that everyone else in Jira can see.
Which links count
Kanban+ reads the two ends of a blocking link:
- inward — "is blocked by": the other issue is a blocker of this one
- outward — "blocks": this issue is a blocker of the other one
A blocker only counts as active while it is not in the Done status category. Once the blocker is resolved, it stops appearing.
How strictly the link type is matched varies by feature, and this is worth knowing:
| Feature | Match |
|---|---|
Board 🚫 Blocked / ⚡ Blocking badges, Dependency Map, Delivery Plan, transition guard, advanced filter | any link type whose name contains "block", case-insensitive |
| Timeline dependency arrows | link type named exactly Blocks |
| Cross-board blocker scan | inward links whose verb contains "blocked" |
So a site that renamed its blocking link type keeps board badges and the Dependency Map, but loses the Timeline's arrows.
On the board
Cards carry 🚫 Blocked when something open is holding them up and ⚡ Blocking when they're holding up something else. Both are computed from a transitive blocker graph — the board follows chains, cycle-safe, so an issue blocked by something that is itself blocked still reads as blocked.
The 🚫 Blocked quick chip and the advanced filter's Blocked is true / is false clause both draw on the same graph.
The Done transition guard uses it too. Set per board in Settings, it decides what happens when someone drags a blocked issue into a Done column: nothing (off), a warning after the move (warn, the default), or a hard stop with a dialog (hard). The guard looks at direct open blockers only.
Dependency Map
Add the Dependency Map subpage from the + tab. It reads every in-scope issue's links in one request and lays out:
- a summary bar — how many issues are blocked, how many are blockers, how many are clear
- a Blocked section — each blocked issue with its open blockers listed underneath
- a Blockers section — each blocker with everything it's holding up
Blockers that sit outside the board's scope are still shown; they open in Jira rather than in the side drawer, since the board didn't load them.
Escalate
A blocked issue on this page has an Escalate button. Write a message, and Kanban+ posts it as a Jira comment on each active blocker, as you, up to five blockers per escalation.
That's the whole mechanism. There's no Slack message, no email, no webhook — Kanban+ makes no calls outside Atlassian. If your team gets Jira comment notifications, they'll get the escalation.
On the Timeline
Turn on Deps and the Gantt view draws arrows between blocking pairs, both ends of which are in the loaded issue set.
- Blue — a healthy dependency.
- Red — a scheduling conflict: the blocker's end date falls after the blocked issue's start date. A banner names the first few.
- Amber bar border, plus an amber dot in the left-hand task list — the issue is on the critical path, computed by topologically sorting the dependency graph and running a forward pass over your real Jira dates.
Board administrators can add a blocker from here by typing an issue key, which creates the Jira link.
See Board & timeline for how the bars get their dates in the first place.
Delivery Plan
The Delivery Plan subpage turns the graph into a schedule using the Critical Path Method.
Every open issue is given the same duration — one divided by the board's daily throughput — and then:
- start = the later of today and the latest finish among its active blockers
- finish = start + that duration
The result is a table ordered so every blocker appears above the work it gates, with a proportional bar showing where each issue sits in the overall span. Critical-path issues are highlighted amber. Issues whose computed finish lands after their due date are flagged red as at risk. Issues caught in a dependency cycle are marked and scheduled last, so a cycle degrades the plan rather than breaking it.
Throughput comes from the daily snapshots the app writes for each board, and falls back to 0.5 issues per day when there's no history yet. You can override the rate on the page.
This is a deterministic single-estimate schedule. For probability rather than a point estimate, add the Delivery Forecast subpage, which runs a Monte Carlo simulation over your historical throughput variance and reports P50 / P85 / P95 dates.
Blockers that cross boards
The Portfolio tab has a Cross-Board Blockers section: issues on one board held up by issues that belong to a different board's projects.
A background job computes this once a day, and you can force a fresh run with ↻ Analyze now on the Portfolio page. Reading the results costs no Jira calls at all — the page reads what the job stored.
For each board the scan queries (projects [AND the board's JQL]) AND (statusCategory != Done OR updated >= -30d) and reads issue links. Then it keeps every inward "blocked by" link whose blocker is not Done and whose project is not one of the projects this board covers.
Each edge records the blocked issue and its summary, the blocker issue and its summary, the blocker's status, and — where it can work it out — which board the blocker belongs to.
The limits, precisely
These are worth reading before you rely on the section.
- 200 issues per board, per run. Boards larger than that are scanned partially.
- A 30-day window. The query only sees issues that aren't Done, plus anything touched in the last 30 days.
- Inward links only. The scan detects "this issue is blocked by that one". It doesn't separately walk outward "blocks" links.
- Board attribution can come up empty. The blocker's board is resolved from a project-to-board map built out of the issues fetched in the same run. A board with no issues in the window contributes nothing to that map, so its projects show as an unknown board — you get the blocker, without a name for where it lives.
- Freshness is daily unless somebody presses Analyze now.
Bottleneck warnings
The Portfolio page also derives bottleneck warnings from the daily snapshots — at most one per board, chosen from three signals. A board with fewer than two snapshots is skipped.
| Signal | Fires when | Escalates to danger when |
|---|---|---|
| Stalled | Work in progress above zero and nothing completed in the window | 5 or more issues in progress |
| WIP breach | WIP is growing and projected to pass the sum of the board's column WIP limits within 14 days | the projection is 3 days or less |
| Accumulating | WIP grew by more than the number of issues completed in the window | — |
Stalled suppresses the other two, and a WIP-breach projection suppresses the accumulating signal. That's how one board ends up with one warning rather than the same problem described three ways.
Related
- Board & timeline — blocked badges, the transition guard, Gantt arrows
- Automation —
is_blocked,has_open_blockersandis_blockingconditions - Data & privacy — cross-board records store issue summary text verbatim