In Jira Cloud Free and Standard plans, Epic is the highest level of hierarchy. But if you have Jira Premium or Enterprise, you can add additional custom levels. You can add levels above the Epic but not levels below it. The Sub-task level will always be the lowest. As an application-level administrator, access the hierarchy configuration page at: Admin > Work items > Work type hierarchy. If the “Create level” button is greyed out, it means additional levels are not supported.
For all Jira plans, the parent field is used to manage relationships and hierarchy. For example, BAKESALE-1 → “Conduct a bake sale“ is the parent of BAKESALE-2 → “Make cookies for the bake sale”.
Here are some hierarchy-related queries to try:
All child work of an item
parent = ITEM-1
An item and its child work
key = ITEM-1 OR parent = ITEM-1
Tip: Use “OR” not “AND” which doesn’t return results. I frequently make this mistake!
The parent examples above don’t return Sub-tasks. To drill down to that level, in Premium or Enterprise, use the portfolioChildIssuesOf function. Where did that function name come from? My unofficial theory is it’s a callback to “Jira Portfolio”, the original name of the “Jira Plans” functionality. Even when Atlassian changes terminology, you’ll sometimes find remnants of old naming in applications and documentation. For example, Jira projects were renamed Jira spaces, but the JQL query is still: project = KEY. Smart values in automation flows are still: {{issue.key}}.
All child items (including Sub-tasks)
issue in portfolioChildIssuesOf("ITEM-1")
Tip: This example has a slightly more modern equivalent. Instead of issue in, you can also use workitemkey in. I prefer issue in because it has less characters.
All child items (excluding Bugs)
issue in portfolioChildIssuesOf("ITEM-1") and type != Bug
If your application doesn’t have the desired hierarchy or JQL capabilities, check out the additional features provided by third-party apps in the Atlassian Marketplace.
Rachel Wright
0 comments