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; } } }

Why do I need Jira Premium in order to create new Hierarchy level 1 work item types in JSM?

Jacob Malony

I have JSM Premium. I don't have Jira Premium. I'd like to build out a few custom work item types and workflows at Hierarchy level 1 (epic level). However, I can't manipulate the Hierarchy at all on the back end. It says I need to purchase Jira premium. Is this accurate or am I missing something?

Accepted answers

Trudy P Claspill

Hello @Jacob Malony

Welcome to the Atlassian community.

Here is my theory. It is just a theory.

The original product was built on a simple concept - one "thing" at the top of the hierarchy (an Epic) that can have a variety of child thing types (story, bug, task). The product was built around the concept. The Epics panel in an Agile board will display only the issues connected to the original Epic issue type.

Later functionality was built to support extending the hierarchy. In order to support that there needed to be a method to visualize the relationships between "things" at all levels. This visualization was not built into the agile boards. Instead the Advanced Roadmaps (Plans) functionality was built. Getting that additional functionality costs more.

That was all built into the self-hosted versions of the products. And then the evolution to Cloud began, and Atlassian did not rework these concepts.

Even with the Premium subscription, new "things" added to Level 1 still will not be treated like Epics in the "original"/Standard product functionality; they won't appear in the Epics panel in boards, they won't create swimlanes if you select Epics for swimlanes in a board, and while Epic Status and Epic Name were still in use, those fields would not be applied to issue types added to Level 1.

All comments

John Funk

Hi Jacob - Welcome to the Atlassian Community!

That does indeed appear to be the case, but not sure why.

I know they will work once you have them available for JSM. You might do a trial of Jira Premium, set up your hierarchy and then turn off the trial on Jira premium. I think that might work.

Just curious though - what is your use case with JSM?

Trudy P Claspill

Hello @Jacob Malony

Welcome to the Atlassian community.

Here is my theory. It is just a theory.

That was all built into the self-hosted versions of the products. And then the evolution to Cloud began, and Atlassian did not rework these concepts.

Jacob Malony

Sounds like creating custom workflows for epic level tickets might be more trouble than it is worth.

Jacob Malony

Interesting idea. Might give that a go.

A work for my local university, for a young school under its banner. I'm looking to increase visibility and efficiency of department and interdepartment work.

I control the jira org, and have set up projects for the various departments. One department has frequent long term project work woth tricky workflows. They also need to be able to hand out work related to the project to various team members.

I figured the Epic -> task -> subtask model would work well for what I need. Epics and child task tickets work well for tracking the handout work, but I'm stumbling trying to figure out the best way to handle their workflows. I don't want to change the default epic workflow, but its also a bit simplistic.

Perhaps I should just keep all the tickets associated with their work at hierarchy level 0 and just link the work, but that seems like a clunky solution where the child work item function provides an elegant solution.

I'm very open to ideas and want to follow best practices as much as possible.

Trudy P Claspill

@Jacob Malony

Why do you not want to change the workflow used by Epics?

If the different projects/teams each need a different workflow for their Epics, that is supported in Jira Standard.

Each project can have workflows that are different from the workflows used by other projects, though within a single project a work item type can have only one workflow associated with it.

Jacob Malony

I could do that, true.

Unfortunately, this department has 3 or 4 different projects of this frequency and complexity. I'd like to have an epic-equivalent work item type exclusive for each of these.

I think that requires premium, yes?

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-service-management-cloud

jira-service-management