Published 2026-10-22 · Facts checked 2026-10-22 · By ArtUp Labs, the maker of ArtUp Query
Short answer. Jira's linkedIssues() takes one work item key and, optionally, link types. For a filter, write one linkedIssues() per key joined with OR. With a JQL function app the filter goes in as the argument: issue in linkedIssuesOf("filter = 10001", "is blocked by") in our ArtUp Query, and linkedIssuesOfRecursive for links of links.
Pick the query for your question
| You want | Plain JQL on Jira Cloud | ArtUp Query |
|---|---|---|
| Work items linked to one item | issue in linkedIssues(ABC-1) | issue in linkedIssuesOf("key = ABC-1") |
| …by one link type or direction | issue in linkedIssues(ABC-1, "is blocked by") | issue in linkedIssuesOf("key = ABC-1", "is blocked by") |
| Work items linked to any item of a filter | One linkedIssues(KEY) per key, joined with OR | issue in linkedIssuesOf("filter = 10001") |
| Work items that have a link of some type | issueLinkType = "is blocked by" | issue in hasLinks("is blocked by") |
| Links of links: a whole chain | No | issue in linkedIssuesOfRecursive("key = ABC-1", "is blocked by") |
| A chain, but only a few levels deep | No | issue in linkedIssuesOfRecursiveLimited("key = ABC-1", "2", "is blocked by") |
A link type is written either by its name ("Blocks", both directions) or by one direction's description ("blocks" or "is blocked by"), as it appears on the work item.
The plain-JQL way, and where it breaks
Atlassian's reference describes the function as searching for work items linked to a work item, optionally restricted to link types. Source: Atlassian, JQL functions, checked 2026-10-22. The reference now spells it linkedWorkItems(); on our test site on 2026-10-22 Jira accepted linkedIssues() and answered linkedWorkItems() with Unable to find JQL function, so try both on your site.
Measured What Jira said on our test site, 2026-10-22 (our keys replaced with ABC-1 and ABC-2):
issue in linkedIssues(ABC-1, ABC-2)
-- Issue link type 'ABC-2' could not be found in function 'linkedIssues'.
issue in linkedIssues(filter = 10001)
-- Expecting ')' or ',' but got '='.
The second key is read as a link type, and a query is a syntax error. So for a filter:
- Run the filter and copy the keys.
- Write one clause per key:
issue in linkedIssues(ABC-1) OR issue in linkedIssues(ABC-2) OR … - Add the link type to each clause if you need one.
Measured For three work items with 27 linked work items between them, the OR of three linkedIssues() returned 27; linkedIssuesOf("key in (…)") with the same three keys also returned 27.
It breaks the same way as the subtasks workaround: the list of keys is a snapshot, so the query does not follow the filter; a filter of a few hundred items makes a query nobody can maintain; and there is no way to go one link further. Jira's own suggestion to nest functions, JRACLOUD-21936, opened in 2010, had 917 votes and the status Gathering Interest on 2026-10-22.
Recursion: how deep, and what about loops
Take a chain where each work item is blocked by the next one:
ABC-1 is blocked by ABC-2
ABC-2 is blocked by ABC-3
ABC-3 is blocked by ABC-4
ABC-4 is blocked by ABC-2 -- a loop
| Query | Result |
|---|---|
linkedIssuesOf("key = ABC-1", "is blocked by") | ABC-2 — one step |
linkedIssuesOfRecursiveLimited("key = ABC-1", "2", "is blocked by") | ABC-2, ABC-3 — two steps |
linkedIssuesOfRecursive("key = ABC-1", "is blocked by") | ABC-2, ABC-3, ABC-4 — the loop back to ABC-2 is not walked again |
- The walk goes level by level and stops at 10 levels;
linkedIssuesOfRecursiveLimitedtakes a depth from 1 to 10. - A work item already visited is not expanded again, so a cycle ends the walk instead of looping.
- The starting items are in the result only if a link leads back to them.
- Without a link type, every link counts — relates to included. A chain over every link type can grow to a large part of a project in a few levels; give a type and a depth.
Measured On our test site with 50,000 issues, on 2026-10-04, linkedIssuesOfRecursive over a test query returned 2,079 work items, exactly the set computed by walking the Jira REST API, and so did the two-level form. On 2026-10-22, linkedIssuesOf over the same query (300 work items) returned 1,783 work items; the set we computed from their links through the REST API also had 1,783, with nothing missing and nothing extra.
Large results and other limits
- More than 1,000 results. Atlassian rejects a JQL function that returns more than 1,000 values; the 1,783 above passed because the function returns a condition, not a list of keys. When a result cannot be returned in full, ArtUp Query answers The result needs n issues; one function returns at most m — never a shorter list. More in nested JQL queries and the 1,000-value limit.
- One link type per call. For two, join two calls with
OR. - Counts of links, such as "at least two blockers", are not supported yet; such a call answers with an error.
- Access. The subquery runs with the app's access, across all projects. Jira still hides work items you cannot see, but a visible item can be returned because it is linked to a matching item in a project you cannot browse. Read the limits before you use it on sites with restricted projects.
- Freshness. Results follow Jira's change events within Jira's API allowance for apps: on our test site a changed link showed in the result in about 15 seconds while the hour's allowance had room; with about 100 functions in use the 90th percentile was about 277 seconds.
Looking for parents and children instead of links? See subtasks of the issues in a filter. Building a coverage view from links — requirements and their tests — is what a traceability matrix does.
Linked work items of any query
ArtUp Query adds linkedIssuesOf, linkedIssuesOfRecursive, hasLinks and 21 more JQL functions to the ordinary Jira search, filters, boards and dashboards. It never writes to your work items.
ArtUp Query is on the Atlassian Marketplace. Sites with up to 10 users use it free.