Impact of Jira Issue-type hierarchy change

[HQRAZAHS]

Hello Folks,

I hope everyone is doing well. My project is using a wrong issue type hierarchy and I am appointed to make a correction in it.

Currently used - Initiative->Feature->Epic->Task/Bug/Story->Subtask
Revised version 1 - Initiative->Epic->Feature/Task/Bug/Story->Subtask
Revised version 2 - Initiative->Epic->Feature->Task/Bug/Story->Subtask

Question 1: Out of the 2 versions above, which one is convenient to use?
Question 2: If the change is made, what will be the impact? I have seen couple of articles and that stated the parent-child relation between Initiative, Epic and Feature will be lost. I understand that.
But apart from this impact will there be any other impact like impact in automations/filters/confluence configurations etc. ?

Thanks in advance.
Ahsan

[Gor Greyan]

Dear @HQRAZAHS

- Yes, the Epic issue type is locked at Level 1 in Jira and can’t be moved below another issue type like Feature. Any new hierarchy level you create (Initiative, Capability) is always placed above Epic.
-  The structure of Version 2 is technically possible in native Jira if it is Premium or Cloud. However, Version 1 works — you just need to remove the Feature from the current hierarchy so it becomes a normal issue type under Epic.

I can see that you are using Premium.

You can check these documents for the custom hierarchy:
https://community.atlassian.com/forums/App-Central-articles/Advanced-Roadmaps-Hierarchy-Configuration-Guide-2025/ba-p/3031309

https://confluence.atlassian.com/advancedroadmapsserver0329/configuring-initiatives-and-other-hierarchy-levels-1021218664.html

https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/

https://support.atlassian.com/jira-software-cloud/docs/configure-custom-hierarchy-levels-in-advanced-roadmaps/

[HQRAZAHS]

ok let me check these links. Thanks for the support @Gor Greyan 

[Gor Greyan]

Dear @HQRAZAHS
Let me know if you need further assistance.

[HQRAZAHS]

@Gor Greyan @Tomislav Tobijas True that the 2nd version is more convenient and robust. But how do I configure it? In my test environment Jira, I tried to configure the 2nd version but I cannot do this. Whenever I create a new level it always goes to the top level, not at the lower level. Moreover, the worktype Epic is non-removable from level 1. Even if I do some tweaks by renaming the levels, the functionality of Epic will always be at the level 1.
On the other hand, 1st version is easily possible, I simply need to delete Feature from my existing hierarchy and it will automatically go the the level 0 (below Epic). 

@Tomislav Tobijas To answer your question, AFAIK in the SAFe recommended hierarchy, Feature cannot be the parent of Epic, it should be vice-versa. Correct me if I am wrong here.

[Tomislav Tobijas]

Hi @HQRAZAHS ,

I'd say convenience depends on your reporting, planning, and parent-child relationship needs, but if you want Features to group Stories/Tasks, version #2 is probably more robust.

Also, a good question is why the current config. is 'wrong'? Looking at some Atlassian recommendations, this structure is fine. Even demo Atlassian sites have it configured this way:

Level	Level name	Jira work types
3	Initiative	Initiative
2	Project/Feature	Campaign Project Feature
1	Epic	Epic Risk Deliverable
0	Story
-1	Subtask

⚠️ Note that you cannot move Epic from level 1; you could rename the default Epic and then use a custom one on levels above/below, but I wouldn't say that's recommended.

As for the impact of changes, what Gor said is pretty much it. It's recommended to review everything and perform some kind of bulk updates before making the 'switch' in hierarchy.

Cheers,
Tobi

[Gor Greyan]

Hi @HQRAZAHS

1. Recommended Hierarchy is version 2: it provides:

• Clearer structure and aligns with SAFe.

• Better for reporting and roll-ups.

• Avoids mixing direct Story/Feature under Epic.

2. Impacts of Change:

• Parent-child links lost (Initiative–Epic–Feature).

• Automations using parent/epic link fields will break.

• JQL filters & boards need updates.

• Advanced Roadmaps hierarchy reconfiguration required.

• Confluence macros/reports may show missing data.

• Integrations/APIs referencing the old hierarchy will fail.

• Historical reports may show gaps or incorrect roll-ups.