How do I find all issues in an epic with JQL?

parent = KEY finds the epic's direct children in any space. In a company-managed space, parentEpic = KEY goes further: the epic itself, its children and their subtasks. On our site parent = PAY-1 found 9 work items and parentEpic = PAY-1 found 11.

Does Epic Link still work in JQL?

It still runs, but Atlassian retired it in February 2024 in favour of Parent. On our site "Epic Link" = PAY-1 found 8 work items where parent = PAY-1 found 9: it missed a subtask placed directly under the epic.

How do I find subtasks of an epic's stories?

In a company-managed space, parentEpic = EPIC-KEY AND hierarchyLevel = -1. In a team-managed space parentEpic does not work, so list the stories: parent in (KEY-1, KEY-2).

How do I find what is blocking an issue in JQL?

issue in linkedIssues("KEY-45", "is blocked by"). The link type is read from the work item in brackets, so for the work items that KEY-41 blocks, write issue in linkedIssues("KEY-41", "blocks").

Can JQL show all children of all epics in a filter?

Not with a sub-query: parent in (filter = "Open epics") is a syntax error. Use parentEpic in (KEY-1, KEY-2) with the epic keys, Premium's portfolioChildIssuesOf() for one key, or an app.

JQL Parent, Epics and Linked Issues: Tested Queries

The release review asks for “everything in the Checkout epic, subtasks too”. Someone types parent = PAY-1, exports the list and sends it. It is nine work items. The epic’s tree actually holds eleven, and the ones missing are exactly the kind people forget: a subtask one level down, and the epic itself.

Jira has four ways to ask “what is under this epic”, and on a live site they gave three different answers. We built one epic on our Jira Cloud test site and ran every query against it on 13 November 2026.

Short answer: parent = PAY-1 finds the direct children in any space. parentEpic = PAY-1 finds the epic, its children and their subtasks, but only in company-managed spaces; in a team-managed space it found the epic alone. "Epic Link" is retired and found fewer. For links, issue in linkedIssues("PAY-45", "is blocked by") lists what blocks PAY-45: the link type is read from the work item in brackets.

One epic, three answers

The test epic, PAY-1, sits in a company-managed space. It has nine children: three stories, three tasks, two bugs and a subtask placed directly under the epic. One of the stories, PAY-4, has a subtask of its own, PAY-28.

Diagram of epic PAY-1 with nine children: stories PAY-4, PAY-5 and PAY-16, tasks PAY-7, PAY-17 and PAY-18, bugs PAY-6 and PAY-11, and subtask PAY-29; story PAY-4 has subtask PAY-28, a grandchild of the epic. parent = PAY-1 found 9, the children but not the grandchild. Epic Link = PAY-1 found 8, missing PAY-29 and PAY-28. parentEpic = PAY-1 found 11: the epic, the children and the grandchild, in company-managed spaces only. In team-managed space SAM1, parent = SAM1-2 found its 3 tasks and parentEpic = SAM1-2 found only the epic itself, with no error. Source: our searches on Jira Cloud and Atlassian's JQL reference.

Query	Found	What it holds
`parent = PAY-1`	9	The direct children
`"Epic Link" = PAY-1`	8	Children, minus the subtask under the epic
`parentEpic = PAY-1`	11	The epic, its 9 children and the grandchild
`parentEpic = PAY-1 AND type != Epic`	10	The same without the epic itself
`linkedWorkItem = PAY-1`	11	The same as parentEpic

linkedWorkItem (and its old name linkedIssue) is not about issue links at all, despite the name: Atlassian describes it as searching “for parent-level work items … and subtasks”, and on our site it returned exactly what parentEpic did.

parent: direct children, any space

parent is the field Atlassian recommends, and it “works for both team-managed and company-managed spaces”. It looks one level down:

You want	JQL
Children of one epic	`parent = PAY-1`
Children of several	`parent in (PAY-1, PAY-2)`
Open children	`parent = PAY-1 AND statusCategory != Done`
Subtasks of one story	`parent = PAY-4`
Stories and tasks with no epic	`project = PAY AND hierarchyLevel = 0 AND parent is EMPTY`

The last one is a useful weekly check: on our site it found 16 stories and tasks in PAY that belonged to no epic.

parentEpic: the whole tree, company-managed only

parentEpic is the only plain JQL that reaches the grandchildren on a Standard plan. Pointed at a story, it returns the story and its subtasks (parentEpic = PAY-4 found PAY-4 and PAY-28).

The catch is in one line of Atlassian’s reference: “Only applicable for company-managed spaces.” We checked what that means in practice on a team-managed space, SAM1, whose epic SAM1-2 has three tasks:

Query	Found
`parent = SAM1-2`	3, the tasks
`parentEpic = SAM1-2`	1, the epic itself

No error, no warning: a filter or a dashboard built on parentEpic in a team-managed space quietly shows only the epic. Use parent there, and list the stories if you need their subtasks.

Two more things that do not work:

parentEpic is a field, not a function: issue in parentEpic(PAY-1) fails with Unable to find JQL function 'parentEpic(PAY-1)'.
A sub-query is not JQL: parent in (filter = "Open epics") fails with Expecting ',' or ')' but got '='.

“Epic Link” is retired

Atlassian: “As of February 2024, Epic link function has been retired in favor of Parent. Existing filters that use the Epic link function still function, but you’ll need to use Parent when creating new filters.” Old filters keep running, and that is the problem: on our site "Epic Link" = PAY-1 found 8 work items, one fewer than parent. Search your saved filters and boards for "Epic Link" and replace it with parent.

Levels: epics, standard work and subtasks

hierarchyLevel names the level by number: 1 for epics (the parent level), 0 for stories, tasks and bugs, -1 for subtasks. Levels above epic that you create in Plans are not covered.

You want	JQL	Found in PAY
Epics	`project = PAY AND hierarchyLevel = 1`	5
Subtasks	`project = PAY AND hierarchyLevel = -1`	3
Subtasks of one epic’s tree	`parentEpic = PAY-1 AND hierarchyLevel = -1`	2 (PAY-28, PAY-29)
Open epics	`project = PAY AND type = Epic AND statusCategory != Done`	5

hierarchyLevel works in team-managed spaces too, where the type names can differ from space to space.

Premium: portfolioChildIssuesOf()

Jira Premium adds portfolioChildIssuesOf("PAY-1"), which follows the full hierarchy including levels above epic. On a Standard site, Jira’s syntax check says This JQL function is only available to Jira Premium users. A saved filter that runs it on Standard does not show that message: our search simply returned no work items.

Linked issues: which way a link reads

A link has two ends. On our site PAY-41 blocks PAY-45, so PAY-45 is blocked by PAY-41. The link type you pass to linkedIssues() is read from the work item in the brackets:

Query	Found	Read it as
`issue in linkedIssues("PAY-41")`	PAY-45	linked to PAY-41 in any way
`issue in linkedIssues("PAY-41", "blocks")`	PAY-45	what PAY-41 blocks
`issue in linkedIssues("PAY-45", "is blocked by")`	PAY-41	what blocks PAY-45
`issue in linkedIssues("PAY-41", "is blocked by")`	nothing	what blocks PAY-41

Several link types go in one call: issue in linkedIssues("PAY-45", "is blocked by", "relates to"). Atlassian calls the type argument case-sensitive; on our site "Blocks" and "blocks" returned the same.

To find work items with a kind of link, rather than links to one work item, use issueLinkType:

Query	Found
`issueLinkType = blocks`	PAY-41 and PAY-45, both ends
`issueLinkType = "is blocked by"`	PAY-45 only
`issueLinkType = "is blocked by" AND statusCategory != Done`	open work that waits on something
`issueLinkType in ("is blocked by", "is cloned by")`	either

The new documentation calls the function linkedWorkItems(). On our site it failed with Unable to find JQL function 'linkedWorkItems(SPR-10)'., so keep linkedIssues() for now. workItemLinkType, the new name for issueLinkType, did work.

What JQL cannot do here

No “has any link”. issueLinkType is not EMPTY comes closest. On our site it also returned a work item whose only link pointed to something we could not see.
No children of a filter’s results. You name the parents by key.
No “blocked by something still open”. JQL can find work items that have a blocker, not whether the blocker is done. Apps such as ScriptRunner add that with their own issueFunction field, which does not exist on a plain site (Field 'issueFunction' does not exist).

When the list of keys gets long, build the query by clicking instead of typing. Our app JQL Blocks does it in Jira, with groups and NOT, and our free JQL builder checks a pasted query for the traps on this page. Every other field and operator is in the JQL cheat sheet; what an epic, a story and a task are for is in Jira epic vs story vs task.

How we tested

Site: our Jira Cloud test site on the Standard plan, 13 November 2026. PAY is a company-managed software space, SAM1 a team-managed one.
How: each query through POST /rest/api/3/jql/parse?validation=strict, then run with GET /rest/api/3/search/jql, and the returned keys compared one by one.
Reference: Atlassian’s JQL fields (Parent, Epic link, Hierarchy level, Work item link type) and JQL functions (parentEpic, linkedWorkItem, linkedWorkItems) pages, read the same day.