You don't need to rename epics (here's what to do instead)

Share on socials

You don't need to rename epics (here's what to do instead)

Georges Petrequin

Published on 29 August 2025

16 min read

An illustrated Jira board showing a hierarchy with levels above epic, and a set of cogs and warning sign

Georges Petrequin

Published on 29 August 2025

16 min read

Jump to section

Why teams rename epics

The cascade effect: how one rename triggers system-wide issues

When renaming epics might actually work

What actually works: two proven approaches

How to build a custom hierarchy (without renaming epics)

Step 2: Visualise your new work type hierarchy

Step 3: Set up your work environment

The bigger lesson

Renaming epic in Jira takes 30 seconds, but triggers a cascade of broken automations, failed reports, and app conflicts. Here's why this simple fix breaks everything, and what actually works instead.

'One of the things I've actually seen, which is a huge no-no, is to go into Jira and rename epic…'

That's what Robert Nadon, Lead Atlassian Architect at Forty8Fifty Labs, told us in a recent conversation.

So, why do teams keep falling into this trap? Because on the surface, it makes perfect sense.

Maybe your team's terminology doesn't match Jira's out-of-the-box hierarchy. Maybe you're following SAFe, or perhaps your industry just speaks a different language than software development.

The obvious fix to all of these? Rename epic to whatever fits your world.

The actual result? You break everything in ways you never saw coming.

So if you're on the fence and are currently deciding whether or not you should rename epic in your Jira Cloud instance, this guide is for you. You'll learn why this seemingly simple change breaks everything, and what actually works instead if you want more flexibility in how you name and organise your work.

Key takeaways

Renaming epic changes the label, not the architecture. Jira still treats it as an epic behind the scenes, which is why everything starts breaking in unexpected ways.
Your entire instance gets the rename, not just your project. When you change epic to 'Feature' for your SAFe team, every other team in your organisation loses their epics too.
Automations and JQL queries fail silently. Every filter using issuetype = Epic returns nothing. Your executive reports show zero initiatives. You might not notice until someone important does.
Most Marketplace apps won't recognise your renamed work items. Most apps are built expecting standard Jira terminology. When they can't find 'epic', integrations break in ways the app doesn't expect.
Every Jira update becomes a potential breaking point. You're not just fixing things once. You're signing up for ongoing maintenance as Atlassian ships changes that could conflict with your customised epic name.
You can get custom hierarchy levels without touching epic. Use Jira Premium's Plans feature to add levels above epic, or apps like Hierarchy for Jira to add levels above or below epic, all while keeping epic as epic!
The fix takes the same 30 seconds as the mistake. Building a proper custom hierarchy is just as quick as renaming epic, but without the months of cleanup work afterwards.

Why teams rename epics in the first place

1. Your industry doesn't speak in epics

Your marketing team thinks in Campaigns. A construction company prefers Projects. A healthcare organisation talks in Initiatives.

When I asked Darren Ching, Product Manager for Hierarchy for Jira, about this, he told me it's relatively common: 'There are many companies that don't come from a traditional IT background or operate outside boundaries of your traditional IT team.' He explained, 'They have their own language that they need to organise their work items by.'

This is a valid reason for renaming epic, but it's still unlikely to be a good idea.

2. The SAFe alignment challenge

If you're implementing something like the Scaled Agile Framework (SAFe) in Jira, you've already discovered the mismatch.

Robert perfectly summarised this: 'For those in the know, Scaled Agile has a different hierarchy. You have your portfolio level and your solution level, and then below that, you'll have epic, capability, and feature... and that does not match up with Jira's out-of-the-box hierarchy!'

Want more insights from Robert on customising Jira to work for SAFe? Watch our recent story with him below!

3. The illusion of simplicity

Here's the dangerous part. Renaming epics feels straightforward. It's just a label change, right?

Unfortunately, Jira's architecture runs deeper than surface labels. Your simple change can trigger a series of failures that you won't see coming before it's too late.

The cascade effect: how one rename triggers system-wide issues

When you rename epic to something else, like 'solution' or 'feature', you're only changing the display name. Jira still thinks it's an epic behind the scenes.

Robert warned us that: 'Every other week, Atlassian is coming up with improvements and changes. If you go in and change some of the default areas of Jira, that could conflict with future changes and cause problems.'

Here's a brief look at what this change might entail:

1. The moment you click 'Save' on your new epic name

'If you rename epics, it applies to every epic within the entire Jira instance', Darren warns.

Your engineering team following SAFe loves their new 'Feature' level, but the design team is frantically searching for their missing epics.

If you have multiple departments working in Jira, things get problematic fast.

2. When your automated processes run next

Your automation rules and reports start failing, often silently. You might not even notice at first.

JQL filters using 'issuetype = Epic' return nothing.
Automated workflows using Jira automation don't recognise the new custom name.
Your weekly portfolio status report that executives rely on suddenly shows zero initiatives in progress.

The only way around that? Revert the name of the work item type to epic (admitting defeat), or start the tedious journey of updating every JQL filter and automation rule in your Jira instance to use the new name.

3. When your apps update or sync

Most Marketplace apps are built with standard Jira terminology in mind. When they can't find 'epic,' integrations fail in unexpected ways:

Reporting apps produce incomplete data because they're looking for epics that no longer exist.
Automation tools that powered your team's workflows require complex workarounds.
Every app update might introduce new conflicts with your renamed work items.

The longer you've used Jira for, and the more your organisation relies on it, the more likely you are to experience these problems as teams across your organisation have unique workflows and ways of working in Jira.

The true cost of renaming a single field

It takes 30 seconds to rename epic, but the downstream consequences can plague your team for months before normality is restored. Even after you've fixed all the immediate problems, you're forever vulnerable. Every Jira Cloud update and every Marketplace app upgrade becomes a potential breaking point that your team needs to be on top of.

Over time, your technical debt compounds and workarounds multiply. Eventually, many teams end up reverting the change anyway, eating the cost of all that wasted effort.

The hidden cost isn't just technical. Your teams start losing confidence in Jira, workflows become fragmented, and what started as a simple terminology preference becomes a multi-month recovery project.

So what should teams do when they genuinely need a different way to organise their work items in Jira?

When renaming epics might actually work

There are limited scenarios where renaming epics might work without causing major issues.

But here's what 'might work' really means:

Everyone agrees on terminology (no separate engineering, marketing, or operations teams with different preferences).
You won't need more than three hierarchy levels.
You have no or very few existing automations or JQL queries using 'Epic' (and are happy to update them all).
You don't use any Marketplace apps (or are willing to check each one for compatibility).
You're starting fresh with minimal historical data.
You're willing to audit all future Jira updates and check for conflicts.

If you tick all the boxes above, renaming epics might work just fine. But if your organisation doesn't fit into the points above, then here are two ways you can get more flexibility:

What actually works: two proven approaches

Despite painting this gloomy picture, there's good news. You can customise Jira's hierarchy to match your need. You just need to be smart about how you do it.

Both solutions we'll discuss share a key principle: they extend Jira's capabilities without fighting its fundamental design.

Path A: create levels above epic with Jira Premium

If you're on Jira Premium or Enterprise, you have a built-in solution with Jira Plans (previously known as Advanced Roadmaps). This allows you to add new hierarchy levels above epic without touching the core structure.

Jira Plans allows you to add levels above epic

Darren notes: 'You can rename your levels above epic to be whatever you want. But if you're on Jira Standard, unfortunately, you're locked into the standard epic → story → sub-task hierarchy.'

But, here’s the catch:

It only works for levels above epic.
Requires Premium (or Enterprise) licences for all users who need access.
Your custom levels are only visible in Plans views, not on standard Jira boards.

But, it’s ideal for organisations that need Portfolio or Solution levels above their epics, as you get the terminology you want without breaking anything, especially if you’re already on Jira Premium.

Path B: build custom work type hierarchies with Hierarchy for Jira

If you're not on Premium/Enterprise, or if you need to add levels both above and below epic, you'll need a different approach. This is where Marketplace apps like Hierarchy for Jira come in.

Many teams have successfully used this approach to solve their hierarchy challenges.

Robert captures the benefits perfectly: 'What Hierarchy for Jira does is allow you to go into the product [Jira] and actually add levels in between both the story and the epic, which really solves the problem.'

This means you don't need to risk renaming epics, and you can have all the flexibility you need in Jira.

Hierarchy for Jira's custom work type hierarchy

Your custom hierarchy is automatically created based on your work item links

For example, if you're implementing something like SAFe, that means your epic stays epic, but you can add Features, Capabilities, Solution, Portfolio, Themes, or whatever else makes sense for your organisation.

Getting started is simple. Let's walk through how this approach works in practice:

Building a custom hierarchy (without renaming epics) with Hierarchy for Jira

For anyone who needs to have custom levels in their Jira hierarchy without renaming epics and isn't ready to upgrade to Jira Premium/Enterprise, the only way to do this is with third-party Marketplace apps, like Hierarchy for Jira.

First, you can install the app and start your 30-day free trial from the Atlassian Marketplace.

We don't make you go through mandatory onboarding calls, and there's no complex setup process.

Once in place, it's time to build your custom hierarchy.

How Hierarchy for Jira creates your custom hierarchy

Hierarchy for Jira reads your existing work item links to automatically build and visualise your custom hierarchy.

This means you can keep your epics as epics while adding any levels above or below them, making Hierarchy for Jira perfect for SAFe implementations or other projects with custom requirements.

Step 1. Create custom work item links to structure your hierarchy

To build your custom hierarchy, you'll use Jira's native work item linking system.

If you need to add new work items to your custom hierarchy, then you can use work item links to do that.

To add levels above epic (like Features or Initiatives):

Open your epic in Jira.
Click "Link work item".
Select your Feature/Initiative and choose the "is child of" relationship.
The Feature/Initiative becomes the parent of your epic.

To add levels below epic (like additional task levels):

Open your story or task.
Click "Link work item".
Select your epic and choose the "is parent of" relationship.
Your custom structure is now in place.

Here's a good primer from Atlassian on linking work items if you need more details.

Link your work items to visualise their relationship in your custom hierarchy

Already have work item links in place? You're one step ahead! Hierarchy for Jira automatically reads your existing work item links and builds your hierarchy from them. No additional setup needed!

Step 2: Visualise your new work type hierarchy

Once your work items are linked, you open the Hierarchy for Jira app and select 'Tree Configuration'.

Choose your preferred work item link type, and your entire custom hierarchy unfolds in a nested tree view.

Your tree view might look something like this:

Multi-level tree view of issues in Jira for SAFe teams

Add as many levels above and below epic as you need

You can sum and roll up progress metrics across your entire hierarchy, so it's easy to see how much effort goes into each feature, epic, and initiative. The rolled and summed up metrics also make it simple to track progress from the Portfolio level, all the way down to individual tasks, so you can report back to stakeholders with ease.

There's another silver lining to using Hierarchy for Jira: since you're not modifying Jira's core architecture, all of your reports, automation rules, and Marketplace apps continue working without interruption.

Step 3: Set up your perfect work environment

Once your hierarchy is in place, you can create different views for different purposes. Quick Filters let you surface exactly what matters for each team or meeting.

Some popular Quick Filters you can create include:

Show Features in the current Program Increment.
Show Blocked work items across all teams.
Show cross-team task dependencies in the current sprint.

Manage your quick filters in Hierarchy for Jira

Quick Filters allow you to customise your hierarchy to only show the key information you need

You can then switch between different views, share them with your team, or turn your filtered view into a Saved View for different audiences:

Daily standup view to show in-progress stories with blockers, so your team can focus on clearing the way for important work.
Executive view showing initiative progress with rolled-up progress metrics to make weekly leadership check-ins easy.
A Program Increment planning view showing all features with child stories and dependencies, so you can balance load across teams and sprints.

Created Saved Views to focus on the information that matters

You can share these Saved Views with a simple URL, export them as a CSV, or embed them directly in Confluence. This makes reporting easier than ever, even for the largest of projects.

This approach makes it simple to help Jira fit into whatever way of working your team follows, without the months of remedial work that follow an epic rename.

The bigger lesson

The urge to rename epics comes from real needs: different teams use different terminology, ways of working like SAFe require new layers above and below epic, and the perceived simplicity of renaming epic makes it seem like a quick change.

But as both Robert and Darren shared, and as many teams have learned the hard way, the solution isn't to fight against Jira's core architecture.

Solving your epic renaming issue comes down to having the right tools.

You can easily add levels above epic with Jira Premium/Enterprise.

Or, you can use Marketplace apps like Hierarchy for Jira to get even more flexibility and add levels above and below the epic level, without needing to rename fields.

Whichever option you choose, the key takeaway is the same: you don't need to rename epics to get the terminology and hierarchy your team needs!

Ready to build your perfect hierarchy, without renaming epics?

Hi there, I'm Jay, Senior Product Marketing Manager for Hierarchy for Jira.

If you're ready to see how Hierarchy for Jira tree lets you build custom hierarchies without workarounds or expensive Jira upgrades, you can start a free 30-day trial—just install the app from the Atlassian Marketplace and get started!

If you have any questions or would like a personalised walkthrough of how the app could work for your unique needs, then schedule a call with our team below. We're here to help!

Start your free trial Schedule a demo

How Forty8Fifty Labs builds a SAFe issue hierarchy

An illustraed Jira board with a custom tree view of work items, lightbulb, and cogs illustration overlaid on top

30 June 2025

Build a custom Jira tree view that reveals hidden dependencies and keeps your team aligned

an illustrated jira board with connected tasks and a tree view overlaid on top

5 March 2025

The busy Project Manager's guide to managing task dependencies in Jira

Written by

Georges Petrequin

Content Marketing Manager

Georges is a Content Marketing Manager at Upscale with a focus on our Jira apps. He spends his time crafting content that helps our customers solve their everyday work pain points and get more out of their Atlassian tools.

Jira

Project Management

Hierarchy for Jira