Cross-team dependencies in Jira, without Premium

Every team works in its own space, and the dates that slip are the ones that cross between them: an epic in Storefront waits on an API in Payments, which waits on a stream in Data. On Atlassian Community it reads “different teams are working on their own boards, but there are frequent dependencies between tasks that need better visibility” (Community, March 2026), or “Upgrading to Premium because of this is not yet an option for us” (Community, October 2025). This page says what Jira shows across spaces by itself, on Standard and on Premium, where each way stops, then what Blockline does.

What Jira does by itself

Links work across spaces. Any issue can block an issue in another space with the built-in Blocks link type: “PAYC-3 blocks STOR-4” means STOR-4 waits on PAYC-3. Each issue lists its links. One issue at a time.
The timeline draws dependencies inside one space. Drag from one epic to another and Jira draws the line, red when the dates overlap (Atlassian). Atlassian’s pricing page lists dependency management as single-space on Free and Standard, and across spaces on Premium and Enterprise (pricing).
Across spaces, Jira Plans. Plans, on Premium and Enterprise, draws dependencies between any issues in a plan and has a dependencies report (Atlassian). Its dependencies are the same issue links (Blocks by default), and it sees an issue only once both ends are in the plan, so someone has to build the plan and keep it current.
The requests are open. Seeing other spaces’ epics on the timeline, JSWCLOUD-17238, has 969 votes and has been open since 2018; JRACLOUD-91560, the timeline across spaces, is under Future Consideration (both read on 7 October 2026).

Is Premium worth it for this?

If your site is on Premium already and someone keeps a plan up to date, use Plans: it draws the dependencies across spaces and reports on them. If the step to Premium is for dependencies alone, weigh what it costs a user a month across the whole site against how many people need the view, and whether anyone will build and keep the plan. Many sites decide it is not, and keep the links they already have.

A search across spaces

JQL reads links in every space you can open, on any plan:

issueLinkType = "is blocked by" AND statusCategory != Done

lists the open work that waits on something. Narrow it to the spaces of one programme with project in (STOR, PAYC, MAPP, DATA). To see what one issue holds up, issue in linkedIssues("PAYC-3", "blocks"). Save the search as a filter and put it on a dashboard with the Filter results gadget, and every team lead sees the same list.

Where it stops:

It shows the waiting side, not the state of the other end. The best answer on that March thread says it plainly: such a filter “returns blocked items, not the state of what’s blocking them”. Whether the blocker is dated, started, owned or already late is a click into each one.
It lists stories, not epics. The link is usually between two stories, so the epic that will miss its date is one level up, and the search does not say which epic a story’s blocker puts at risk.
It knows no dates. A blocker due after the work waiting on it looks the same as one due a month before.
It may not keep the two sides apart. A link-type search matches the type’s name and both its descriptions, and with the built-in Blocks type, whose name and outward description are both “blocks”, the waiting side and the blocking side come back together; JRACLOUD-98637 reports the same for “is blocked by” (filed June 2026). Check a few results by hand before trusting the list.

Before any tool helps, the links have to say the same thing in every team: one link type in one direction, stories linked to what they wait on, and a date on both ends. What data your teams need is the checklist; it holds for a search and for Plans as much as for an app.

A spreadsheet from the export can add the dates, a column at a time, every week; A dependency report for the steering meeting walks through it.

With Blockline

Blockline is our app. It reads the Blocks links your teams already make, across any spaces, on Standard or Premium, and judges every epic:

Open Apps › Blockline, pick the spaces of one programme under Scope (or a saved filter, or JQL), and press Show risk.
The board opens on the answer: “5 of 8 open deliverables At risk or Blocked”, with the count at each level.
Every epic follows, worst first, with its reason in one sentence: “Blocked by PAYC-3 via STOR-4, 13 Nov (due date), 6 days after this epic’s date”. The blocker, the story it comes through, its date and where the date came from.
Open blockers says which teams to call: “3 · DATA, MAPP, PAYC”.
Team matrix counts the open dependencies between each pair of spaces, with the worst level; pick a cell for the list.
Save as my default opens the same spaces next time.

How it judges, so the board stands up when someone checks it:

Seven rules over every link: a blocker due after the waiting issue’s date, one with no date, one still To Do close to the date, one in progress for two weeks or more, one with no assignee and no sprint, a circular dependency, and work past its own date (How risk is judged).
An epic waits on everything its stories wait on outside it, and the worst level rolls up to the epic and its initiative.
Every date says where it came from: the due date, Target end, the sprint’s end, a release date or the latest child (Where dates come from).
Every read is made as the person looking, so an issue Jira hides from them is left out, as in Jira.
A view judges up to 5,000 issues, counting children and linked issues; past that it says so and shows no partial numbers.

If your teams link with “depends on” rather than Blocks, a Jira admin adds that link type in Settings. What each team needs to keep in Jira is in What data your teams need. More on the Blockline home page.