Adding multiple Issue Type in Jira Hiearchy

[Tam Do]

Hello,

We currently use the default work type hierarchy: Functional Area → Initiative → Epic → Story → Sub-task (attached).

Recently, we added custom Jira work types to align with our organizational needs and team terminology, with custom schemes depending on the issue type. We would like to add these custom work types to the Jira hierarchy so we can leverage the built-in functionality (e.g., timeline).

Jira has a setting that allows associating multiple work/issue types at the same hierarchy level, but my concern is whether adding a new work/issue type will break any existing linking. For example, if I add my custom work type Agency to the Epic level, will this break any existing links between Epics and the new Agency type? And will my custom work types inherit all the built-in Epic functionality?

[Evgenii]

Hi, @Tam Do 

You can add new issue types to hierarchy and it won't affect on any existing issue links. It's just expansion of hierarchy tiers. 

And now there is no Epic terminology. It's deprecated. All issues have parent-child issue linkage through Parent field.

[Tam Do]

Hi @Evgenii ,


Are you saying that adding a new Issue type to the hierarchy (Epic) will deprecate the existing Epic hierarchy setting?

[Evgenii]

No, absolutely no.
I was talking, that field Epic Link, is now deprecated. 
I'm telling, that Epiс now - is just issue type, which is above ordinary issues. 
You can add another issue type, and add it to hierarchy level, where Epic is located, and it will have absolutely same functionality.

[Joshua Brock _ Seibert Group_ GmbH]

Greetings @Tam Do and welcome to the Community!

Good news on your main concern: adding a new work type at an existing hierarchy level will not break your existing links. In modern Jira, hierarchy behavior is tied to the *level*, not the type name.

As mentioned, parent-child relationships now run through the Parent field (the old Epic Link is deprecated), so when you place your custom "Agency" type at the Epic level, it uses the same linking mechanism every other Epic-level type uses. Your existing Epic-to-Story links stay intact, and the new type inherits the same level of behavior, including Plans, timeline, and roadmap support.

Two things worth checking for a clean rollout: make sure each project that needs the new type actually includes it in its work type scheme (otherwise people won't see it as an option when creating items), and decide up front which level each custom type belongs to, since that's what drives the built-in functionality you're after.

One honest caveat: once you start layering several custom work types across multiple levels, the native hierarchy view can get visually busy and harder to navigate. That is usually the point where teams scaling beyond a single project start looking for a more structured layer on top.

If your hierarchy is heading toward scaled agile (multiple teams, portfolio-level work, SAFe), that's where our app Agile Hive may be worth a look. It's the operating model for SAFe inside Jira rather than a planning add-on, so the hierarchy is enforced by the data model rather than maintained by hand:

• Full Portfolio → Solution → ART → Team hierarchy modeled natively in Jira, so work and reporting stay scoped automatically.
• Native Program Increment (PI) planning and execution, with per-team and cross-team views built from the same data.
• Full SAFe hierarchy enforcement and dependency management out of the box.
• Everything stays inside Jira — no separate system of record and no data sync to keep aligned.
• Configuration-based setup, so most teams are live in their first ART in weeks, not months.

You can read more at https://www.agile-hive.com, and there's a free trial on the Atlassian Marketplace if you'd like to test it against your current hierarchy setup.

And I always like to include a note of disclosure in that I work at Seibert Group, the team behind Agile Hive. Hope this helps, best of luck, and again, welcome!


Joshua
Content Writer & US Representative
Agile Hive and Aura Apps (products of Seibert Group GmbH)

[Olga Cheban _TitanApps_]

Hi @Tam Do !

Yes, adding custom work types to existing hierarchy levels is safe. Your existing links between Epics and other work items will not break, and the new Agency work type placed at the Epic level will inherit the same hierarchy behavior, including timeline and Plans support.

A couple of things worth knowing for your setup:

• Hierarchy behavior is determined by level, not by work type name. Once you assign Agency to the same level as Epic, it will be treated as a parent of Stories and behave consistently across Plans, timeline, and roadmap views.
• As Evgenii mentioned, the old Epic Link field is deprecated. Parent-child relationships now run through the Parent field, so any new work type you add at a hierarchy level uses the same linking mechanism as Epic. This is also why adding new work types is non-destructive: nothing reroutes existing links.
• Just make sure each project that needs Agency actually includes it in its work type scheme, otherwise users will not see it as an option when creating items.

For a full walkthrough on configuring custom hierarchy levels and assigning work types to them, you can check my article: Advanced Roadmaps Hierarchy Configuration Guide 2026.

One side note: once you start adding several custom work types across multiple levels, the native hierarchy view can get hard to follow visually. If that becomes a pain point later, our solution Smart Hierarchy gives you a tree view of how all your work types connect across levels, which is helpful for navigating more complex structures.

Hope this helps!