Pulling in a Space and all linked items in Plans

Greetings @Alex Smyers 

I think your read of the current limitation is correct.

Jira's native JQL can return work items linked to a **specific** work item using `linkedWorkItems()`. What it can't currently do is take a whole Space as the starting set and dynamically return everything linked to any work item in that Space. That's essentially the limitation tracked in JRACLOUD-18679.

So for something like:

**Space A + every work item linked to anything in Space A**

you'd currently need to enumerate the individual work items in JQL or use an app with extended JQL capabilities, such as ScriptRunner. There isn't a native dynamic filter that will expand the entire Space that way.

One thought, though, depending on *why* you're trying to build the filter:

If the goal is less about the Plan source itself and more about maintaining a high-level view of dependencies across several teams or Spaces, that's a problem Agile Hive approaches differently. And in full disclosure, I work at Seibert Group GmbH, the team behind it.

For organizations working with SAFe, Agile Hive provides an ART Planning Board that shows planned work across the teams on an Agile Release Train and visualizes dependencies between work items. Dependencies can also include work from outside the Agile Hive hierarchy, which is displayed as external work, and Agile Hive evaluates those dependencies as healthy, at risk, or critical based on the current plan.

There's also a Dependency Overview that provides a consolidated view of internal and external dependencies.

That wouldn't give you a generic replacement for `linkedWorkItemsOf("Space = X")` in native JQL. Agile Hive is structured around ARTs, PIs, and team planning, so it would only make sense if the broader dependency-planning use case is what you're ultimately trying to solve.

Hope this helps,

Joshua
Content Writer & US Representative
Agile Hive and Aura Apps (products of Seibert Group GmbH)

Hi @Alex Smyers ,

Full disclosure: I work for Huminder, the company that builds Board Studio.

Your reading is correct. For a Plan's work source, native JQL cannot express:

Space Y OR every work item linked to a work item in Space Y

JQL does not traverse generic work-item links, which is the limitation tracked
in JRACLOUD-18679. The ScriptRunner query Trudy shared is the direct answer if
you need that exact result set inside Plans.

I think the important distinction is between two related needs:

1. Build an exact source for a Plan. This requires link-aware JQL from an app
such as ScriptRunner or an equivalent approach.

2. Understand the delivery impact of work in one Space. Here, a dependency
view can help even if its source is broader than the result you want to see.

That distinction matters because both native alternatives have a cost: loading
only the originating Space hides external dependencies, while adding every
possibly related Space can make the Plan noisy.

Board Studio is one possible complementary approach. It does not make native
JQL traverse links, and it does not produce that dynamic source for Plans.
Instead, you load a deliberately broad Jira filter covering the relevant
Spaces, then inspect the connected Jira context from the Story or Task you are
investigating.

In a test dataset, I loaded 136 work items across six Jira Spaces and selected
the Story BAC-4 — High-value payment approval workflow. At three link hops,
the impact analysis found two upstream and twelve downstream work items across
three Spaces, including Stories and Sub-tasks in two external Spaces.

Starting from one Core Services Story, Show impact on board highlights its
downstream cards and dependency paths across the broader Jira dataset while
preserving team, sprint and hierarchy context.

The Inspector identifies the external Stories and Sub-tasks, whether they are
upstream or downstream, and how many Jira-link hops away they are. Jump directly to any of them is one click, it will switch hierarchical level if needed

The broader scope keeps the external work available. From there, Show impact
on board highlights the connected cards and dependency paths, while the
Inspector reports the upstream and downstream work. Jira's native hierarchy
and work-item links remain the source of truth.

Once that context is visible, the AI-assisted Inspector can also assess the
selected work for delivery risk. That is a second step: it interprets the Jira
context already loaded rather than inventing or fetching missing dependencies.

This is where the two views can be complementary: Plans remains useful for
planning and scheduling, while a dependency-focused view helps answer what a
selected Story or Task depends on, what it may affect, and which teams or
Spaces own that work.

So my practical recommendation would be:

- if the exact “Space plus linked work” result must be the source of the Plan,
use link-aware JQL;
- if the underlying need is to investigate connected delivery risk without a
Space-only source that omits external work, consider a broader source plus
item-level impact analysis.

My 2 cents, Fred

Hi @Alex Smyers,

To the best of my knowledge this is not possible in Plans. JQL has no way to walk links, which is exactly JRACLOUD-18679. Without a function like ScriptRunner's linkedIssuesOf there is nothing to put in the query, so the answer for Plans itself is no.

If a different surface is acceptable, and you are open to solutions from the Atlassian Marketplace, JXL for Jira (the app my team and I work on) gets there without the traversal. A custom structure using Linked work items as the parent relationship builds the tree from the links themselves rather than from the query, and you can give the top level its own filter so your space's stories and tasks sit at level 1 with everything they link to nested underneath, whichever space those live in.

One thing to know about scope. The sheet has to load the spaces those links reach into, so point its scope wide. That only governs what gets loaded, not what you see: with the top level filtered to your space, the table still shows just those stories and tasks plus whatever they link to, so you do not get the everything-at-once problem you hit when adding whole spaces to a Plan.

The honest limitation is the shape. At this is point this a table, but we are currently working on a timeline view as well.

Best, Martin

Hello @Alex Smyers 

Can you provide more details on exactly what you mean by "all items linked to items within that space"?

Are you talking about the generic linking functionality or the parent/child relationships?

You mentioned that this is not about Epics but rather about stories/tasks, so I think you mean generic linking.

And you mentioned ScriptRunner.

You can find information on the JQL functions from ScriptRunner that relate to links and relationships here:

https://docs.adaptavist.com/sr4jc/latest/features/scriptrunner-enhanced-search/scriptrunner-enhanced-search-jql-functions/links-and-relationships

If your plan is bringing in all items from Space Y and you want also all items directly linked to Space Y items then your plan query would be:

project=Y or issuefunction in linkedIssuesOf("project=Y")