Jira issue type hierarchy:
levels and the whole tree

The right view depends on your task. Scheduling a release calls for dates and dependencies. Reading the work below an epic calls for a clear list of children. These are related needs, but they do not require the same interface.

Jira hierarchy levels: epics, stories, tasks and subtasks

Every Jira Cloud site starts with the same three levels. Atlassian numbers them, which is useful when you read its documentation or configure the hierarchy later.

• Level 1, epic: a larger body of work that groups related work items. See the Jira epics guide.
• Level 0, standard work items: stories, tasks and bugs, plus any custom work types at this level.
• Level -1, subtask: a smaller piece of a standard work item. A subtask can’t have child work items.

Stories, tasks, and bugs are all standard work items. They normally sit alongside one another, rather than forming a chain from story to task to bug. See Atlassian’s explanation of work types, or epic vs story vs task for when to use each one.

Imagine a small team improving a checkout flow. An epic represents the wider effort. A story describes a customer-facing outcome, a task covers implementation work, and a bug tracks a defect. Subtasks break a standard work item into smaller pieces.

Work items, work types and the Parent field

Atlassian now says “work item” for issue and “work type” for issue type, so older articles and many teams still use the old names for the same things. Each work item points to the one above it through its Parent field; in JQL, Atlassian retired Epic Link in favor of Parent in February 2024.

Team-managed spaces differ in one detail: their subtasks can’t sit directly under an epic. See Atlassian’s notes on subtasks in team-managed spaces.

A hierarchy is also different from a link. Two work items can be related, or one can block another, without either becoming the other’s parent. Before choosing a view, check whether you need parent and child nesting, dependency links, or both.

Adding hierarchy levels above epic: initiatives and themes

On Jira Premium and Enterprise, a Jira administrator can add levels above epic, for example an initiative or a theme. Atlassian describes these extra levels as a way to track your organization’s larger initiatives in your plans. The setting is at Settings > Work items > Work type hierarchy. New levels are created at the top of the hierarchy, and the change applies to all company-managed spaces on the site. See Atlassian’s guide to configuring the work type hierarchy.

Plan the levels before you create them. Atlassian warns that hierarchy changes can break existing parent and child relationships and can’t be undone. Creating new levels is not part of Jira Free or Standard, and no plan adds a level between standard work items and subtasks.

Viewing hierarchy is not configuring hierarchy

A tree view displays relationships. Configuring hierarchy changes which levels and parent relationships your Jira setup supports. Opening a different view does not create an initiative level, place tasks beneath stories, or change your organization’s work types.

Cascade’s tree is a browsing interface for existing work. Do not treat it as a hierarchy configuration tool or a promise of arbitrary levels above epic.

How to see the hierarchy in Jira

Jira already has several ways to inspect and organize work. Availability and labels can vary with your plan and space configuration.

Timeline: useful when dates matter

The Jira Cloud timeline can show parent work and the standard-level children below it when child planning is enabled, which it is not by default. Atlassian documents this as level 1 and level 0; its child-planning documentation says the subtask level is not shown. This is useful for scheduling, but is not the same as browsing every level of a hierarchy. See child work item planning on the timeline.

In a software space’s timeline, View settings has a Show inline hierarchy toggle. With it on, child work items are indented beneath their parent; with it off, the timeline switches to a flat layout. See Atlassian’s timeline view settings.

Plans: a broader planning context

Jira Cloud Premium and Enterprise include advanced planning features. In a plan, the “Show full hierarchy” filter option can retain children belonging to filtered work items even when those children do not match the filter. This is worth checking if your team already works in Plans. Atlassian explains how hierarchy and filters work together.

JQL: find the children of a work item

In search, parent = SHOP-100 returns the direct children of SHOP-100, in both team-managed and company-managed spaces, and parent in (SHOP-100, SHOP-200) covers several parents. It returns one level at a time, so the subtasks of those children need a second query. In company-managed spaces, parentEpic = SHOP-100 returns both levels. For boards, backlogs and subtask searches, see how to show Jira subtasks under their parent. See Atlassian’s JQL field reference.

List: a straightforward field-based view

The native list is useful for scanning, sorting, creating, and editing a space’s work. If your immediate question is who owns a work item or which status it has, that may be enough. See Atlassian’s overview of the list view. Choose by the workflow you need, rather than assuming every task needs a tree.

Why filtering flattens the hierarchy

Sorting the list keeps child work items with their parent, according to Atlassian’s list sorting notes. Filtering is different. Atlassian’s filter documentation says that when a filter is applied, parents and subtasks that match still appear, but child work items are not nested under their parent. Users notice it as soon as they filter by assignee: in an Atlassian Community thread, a Community Champion answered that this is by design and that expand and collapse are turned off while a filter is on.

×

Seeing the whole hierarchy as a tree

A tree view helps when context matters more than dates. You might want to read all the work below an epic, understand which subtasks belong to a story, or inspect a detail without losing the surrounding list.

For a developer, that can mean reviewing an assigned work item in the context of its parent. For a team lead, it can mean checking related work together. A project manager or business analyst may find the same arrangement useful when reading scope and acceptance criteria.

Filtering introduces a trade-off: a shorter result list is easier to scan, but removing parents can hide context. In Cascade, a filter keeps each match inside its parents by default, so filtering to one assignee still shows which story and epic their work belongs to. When you want just the matches, switch the result layout to “Matches only” for a flat list.

A practical workflow with Cascade

1. Install from the official store listing. Cascade is a Chrome extension for Jira Cloud, not an Atlassian Marketplace app. Check your organization’s extension policy first. To see how it compares with Marketplace apps, read Jira hierarchy plugins compared.
2. Open your Jira Cloud workspace. Cascade uses your existing signed-in session; it does not require a separate Cascade account or API token.
3. Click the floating Cascade button. On the Jira page, it first appears along the right edge. Cascade opens in your Jira tab, starting on “Assigned to me.” From there, stay with your assigned work or choose epics, then browse their trees down to subtasks. Use search and filters to focus on the work you need.
4. Inspect the details. Open a work item’s detail pane to read information and comments while retaining the surrounding context.
5. Review supported changes or export. Update indicators and supported diffs answer a different question from current details. For spreadsheet work, download CSV or copy the current view for Excel; the Jira to Excel guide compares this with Jira’s own export. Some of these, such as indented export, are planned for Cascade Pro and are free for everyone during early access; join the waitlist to hear when Pro opens.

×

The Cascade homepage includes an interactive demo with sample data, and answers about access and privacy. Review those before deciding whether the extension fits the way you work.

Know the boundaries

Cascade is intended for Jira Cloud on atlassian.net in Chrome. This guide does not promise compatibility with Jira Server, Data Center, every browser, or Jira Product Discovery. Product Discovery’s ideas and discovery workflows should not be assumed to follow the software workflow described here.

Jira administrator installation is not needed according to the store listing. Employer-managed browser policies can still restrict installation. The extension also works within your existing Jira access; it is not a way to view work you do not have permission to see.

The Inbox starts from installation and does not recover an earlier notification history. Supported description and acceptance-criteria diffs should not be confused with a complete historical audit of every field. Likewise, a hierarchy export preserves the current view’s structure; it is not a replacement for portfolio planning.

According to the extension privacy information, processing and caching are local, with normal requests to your Jira instance. Exported files and anything you copy remain your responsibility to store and share appropriately.

Jira hierarchy FAQ