nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Issue Types and Hierarchy

Harun Temel

Hi everyone,

I have two scenarios where I need to create an issue hierarchy in Jira, but I’m not sure how to set it up properly. I would really appreciate your help in figuring this out.

Could you please guide me on how to structure the hierarchy for different issue types?

Ekran görüntüsü 2025-02-05 232749.png

I have two scenarios where I need to create an issue hierarchy in Jira. I couldn't make any progress on Option 1, but for Option 2, I tried a setup similar to the one shown in the image below.
Ekran görüntüsü 2025-02-05 233125.png

However, I'm not sure if this is the correct approach or if there's a better way to achieve the desired hierarchy. Could you please guide me on how to properly configure it?

Thanks in advance!

Accepted answers

Valerie Knapp_dpp5c6

Hi @Harun Temel , welcome to the Atlassian Community and thanks for your question.

First, you have to have the premium tier (I believe) to have the customisable hierarchy so best to check this first.

Second, in both of the diagrams, you have the bug at two different levels in the hierarchy (from how I'm reading it).

Basically, you can have 4 levels of hierarchy, but the issues need to always be at the same level

So you could have something like this

Level 4 - Program

Level 3 - Epic

Level 2 - Bug / Story / Task

Level 1 - Subtask

If you wanted to put a level underneath the Subtask, you would have to create another type of task, like a sub-bug

You can't have the bug at level 2 and 1 or 0 (in a hypothetical model with 5 levels).

Does that make sense?

Happy to hear your thoughts.

Best wishes

Trudy P Claspill

Hello @Harun Temel

Welcome to the Atlassian community.

Adding to this what @Valerie Knapp has shared...

Before going off into my long-winded explanation I'd like for you to step back and think about your use case.

What problem are you trying to solve with this hierarchy?

Why do you need to have these various parent/child relationships between issues?

Could any of these relationships be address with the native generic issue linking function instead? Issue linking does not convey any parent/child relationship when it comes to Jira functionality.

And here is the long-winded explanation:

Jira has three levels in the issue type hierarchy natively.

Level 1: Epic
|-- Level 0: standard issue types (i.e. Task, Story, Bug)
    |-- Level -1: subtask issue types

Some important things to note about this structure:

You cannot insert levels in between these.
You cannot add levels below Level -1.
Issues at Level -1 cannot exist except as children of issues of the types at Level 0. For comparison, issues of types at Level 0 can exist without being children of an issue type at Level 1.
A given named issue type can exist at only one Level.
You cannot skip levels when creating parent/child relationships. Children issue types can come only from the level directly below. Parent issue types can come only from the level directly above. If both "Task" and "Bug" are at Level 0, they can only ever be siblings. The hierarchy will not allow you to make one a child of the other. And an issue type at Level -1 cannot be a child of an issue type at Level 1 (cannot skip Level 0).
Issue type names must be unique. If you want to have "Bug" available at different levels you have to create an issue type for each level and give the issue type a unique name for each level.
With a Free or Standard Subscription plan you can
1. Add more issue types at Level 0 and at Level -1 only, not at Level 1
2. Rename to native issue type called "Epic" to something else (like Feature), but that native issue type remains locked at Level 1.

With the Premium (and Enterprise) subscription plans, as @Valerie Knapp noted you can add more hierarchy levels above Level 1. In that scenario you add the levels, create a new issue type initially as a Level 0 issue type, then move that new issue type to the new Level you created somewhere above Epic. The number goes up from Level 1. "Level 2" would be the level of issue types that can be parents of Level 1. "Level 3" would be the level of issue types that can be parents of issue types at Level 2.

So you cannot actually create a level below the current Level -1/Subtask.

From this image you shared:

Ekran görüntüsü 2025-02-05 233125.png

...it is clear that you have at least a Premium subscription, because you have added Levels 2 and 3. Can you show us the entire hierarchy.

With option 2 the portion you have where Bug and Subtask can be either a parent or a child of each other is not possible. As stated, a given issue type can exist at only one level.

With what you have shown us, at Level 0 you could have issue types "Bug-L0" and "Subtask-L0". At Level -1 you could have two subtask issue types "Bug-L-1" and "Subtask-L-1". These would be 4 distinct issue types.

Screenshot 2025-02-05 at 4.12.14 PM.png

To add Option 1 into the mix you can re-use some of Option 2. You would have to add a third "Bug" issue type. And you could not create the parent/child link between Epic and Task.

Screenshot 2025-02-05 at 4.14.34 PM.png

Issue type hierarchy is a global setting for Company Managed projects. (More about Team Managed projects in a moment.) You cannot have different hierarchies for different projects.

You can limit which issue types are available within a single project if you want to contain all the issues in the hierarchy within the project. So, for project using Option 2, you would just exclude the Bug-L1 issue type from the Issue type scheme.

As for Team Managed projects:

The issue types you define in the Jira Settings > Issues > Issue Types are not directly available in Team Managed projects. Issue Types available in Team Managed projects are defined directly within each Team Managed project.
Within a TM project you can have only the 3 native hierarchy levels; 1, 0, and -1.
Within a TM project you can have only one issue type at Level -1, and only one issue type at Level 1.
To connect Level 1 issues in a Team Managed project to Level 2 issue types, the Level 2 issue types have to be created in a Company Managed project.

I hope this information is useful to you. Let us know if you have more questions.

All comments

Valerie Knapp_dpp5c6

Hi @Harun Temel , welcome to the Atlassian Community and thanks for your question.

First, you have to have the premium tier (I believe) to have the customisable hierarchy so best to check this first.

Second, in both of the diagrams, you have the bug at two different levels in the hierarchy (from how I'm reading it).

Basically, you can have 4 levels of hierarchy, but the issues need to always be at the same level

So you could have something like this

Level 4 - Program

Level 3 - Epic

Level 2 - Bug / Story / Task

Level 1 - Subtask

If you wanted to put a level underneath the Subtask, you would have to create another type of task, like a sub-bug

You can't have the bug at level 2 and 1 or 0 (in a hypothetical model with 5 levels).

Does that make sense?

Happy to hear your thoughts.

Best wishes

Trudy P Claspill

Hello @Harun Temel

Welcome to the Atlassian community.

Adding to this what @Valerie Knapp has shared...

Before going off into my long-winded explanation I'd like for you to step back and think about your use case.

What problem are you trying to solve with this hierarchy?

Why do you need to have these various parent/child relationships between issues?

Could any of these relationships be address with the native generic issue linking function instead? Issue linking does not convey any parent/child relationship when it comes to Jira functionality.

And here is the long-winded explanation:

Jira has three levels in the issue type hierarchy natively.

Level 1: Epic
|-- Level 0: standard issue types (i.e. Task, Story, Bug)
    |-- Level -1: subtask issue types

Some important things to note about this structure:

You cannot insert levels in between these.
You cannot add levels below Level -1.
Issues at Level -1 cannot exist except as children of issues of the types at Level 0. For comparison, issues of types at Level 0 can exist without being children of an issue type at Level 1.
A given named issue type can exist at only one Level.
You cannot skip levels when creating parent/child relationships. Children issue types can come only from the level directly below. Parent issue types can come only from the level directly above. If both "Task" and "Bug" are at Level 0, they can only ever be siblings. The hierarchy will not allow you to make one a child of the other. And an issue type at Level -1 cannot be a child of an issue type at Level 1 (cannot skip Level 0).
Issue type names must be unique. If you want to have "Bug" available at different levels you have to create an issue type for each level and give the issue type a unique name for each level.
With a Free or Standard Subscription plan you can
1. Add more issue types at Level 0 and at Level -1 only, not at Level 1
2. Rename to native issue type called "Epic" to something else (like Feature), but that native issue type remains locked at Level 1.

So you cannot actually create a level below the current Level -1/Subtask.

From this image you shared:

Ekran görüntüsü 2025-02-05 233125.png

...it is clear that you have at least a Premium subscription, because you have added Levels 2 and 3. Can you show us the entire hierarchy.

With option 2 the portion you have where Bug and Subtask can be either a parent or a child of each other is not possible. As stated, a given issue type can exist at only one level.

Screenshot 2025-02-05 at 4.12.14 PM.png

To add Option 1 into the mix you can re-use some of Option 2. You would have to add a third "Bug" issue type. And you could not create the parent/child link between Epic and Task.

Screenshot 2025-02-05 at 4.14.34 PM.png

Issue type hierarchy is a global setting for Company Managed projects. (More about Team Managed projects in a moment.) You cannot have different hierarchies for different projects.

As for Team Managed projects:

The issue types you define in the Jira Settings > Issues > Issue Types are not directly available in Team Managed projects. Issue Types available in Team Managed projects are defined directly within each Team Managed project.
Within a TM project you can have only the 3 native hierarchy levels; 1, 0, and -1.
Within a TM project you can have only one issue type at Level -1, and only one issue type at Level 1.
To connect Level 1 issues in a Team Managed project to Level 2 issue types, the Level 2 issue types have to be created in a Company Managed project.

I hope this information is useful to you. Let us know if you have more questions.

Harun Temel

Thanks! Your explanation was clear—I get that issues must stay at the same level and a premium tier is needed for customization. Appreciate the help!

Harun Temel

First of all, thank you very much for this detailed explanation. I'm sharing my entire hierarchy below. I can't answer the three questions you asked above—I don't have much knowledge about how it would make things easier or the other parts. I just want to learn whether these scenarios are possible in Jira, and if they are, implement them.

Ekran görüntüsü 2025-02-06 182900.png

Hannes Obweger - JXL for Jira

Hi @Harun Temel

just to add to the previous answers:

The one concept that would give you full flexibility in modelling issue hierarchies, and does not require Jira Premium, is issue linking. Issue links can be created between any pair of issues, and signify any kind of relationship - including parent/child. The downside is that Jira doesn't really recognise an issue link as a parent/child relationship, and therefore won't give you a lot of hierarchy-related features.

There are, however, a number of hierarchy-focused apps on the Atlassian Marketplace that can do so. E.g., you may want to have a look at the app that my team and I are working on: JXL for Jira.

JXL is a full-fledged spreadsheet/table view that allows viewing, inline-editing, sorting, and filtering by all your issue fields, much like you’d do in e.g. Excel or Google Sheets. It also comes with a number of advanced features, including the support for configurable issue hierarchies. These issue hierarchies can be based on Jira's built-in parent/child relationships (like epic/story, or task/sub-task, or whatever is defined in Jira Premium if you have it), and/or based on issue links of configurable issue link types (like is parent of / is child of).

This means that, if you don't have Jira Premium, you can still model any number of hierarchy levels based on issue links.

This how it looks in action for a 5-level hierarchy:

I should add that you don't need Jira Premium for this to work.

Any questions just let me know,

Best,

Hannes

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

jira-cloud-administration

not-applicable