This missing feature is a huge blocker and showstopper for Jira Plans in our organization. Please let me explain the reasons why:

• Projects vary in complexity, and certain projects may require a more detailed or simplified hierarchy. Providing flexibility at the project level allows teams to adapt the hierarchy to the unique demands and intricacies of their project without affecting other projects.
• Introducing a new tool or methodology across an organization can be challenging. Allowing per-project configuration would make it easier for our teams to adopt Advanced Roadmaps (Plans) gradually. Our Teams could transition at their own pace, and project-specific customization facilitates a smoother adoption process.

• Our Teams often have specific reporting and analysis needs based on their project objectives. A per-project configuration would allow our team to define hierarchy levels that align with their reporting requirements, leading to more meaningful insights without affecting the reporting structures of other projects.

• Last but not least: The one and only standard hierarchy does not exist for customers who are using Jira through their entire organization and departments and not only for software development. Where agile and classic methods collide, it is a huge challenge to get the hierarchy levels aligned across all projects. A must-have feature for our company is the ability to set hierarchy levels required or optional for each project.

Thank you for taking these insights under consideration.

Kind regards,

Chris

Dear all,
I would like to inform you that this issue in the project JPOSERVER is being migrated to the new project JSWSERVER. Your votes and comments will remain unchanged.
Our team at Atlassian will continue to monitor this issue for further updates, so please feel free to share your thoughts or feedback in the comments.
Sincerely,
Aakrity Tibrewal
Jira DC

We recently started evaluating Plans after moving to Data Center and while some of our team is excited about the potential, the reality with the global hierarchy is that the value of Plans is limited to only a handful of projects in our organization.

A single global hierarchy is stopping other teams on-boarding to Advanced Plans.  I appreciate that some organisations have the same hierarchy, but the system I work on supports multiple organisations and each has their own way of doing things.

Hello there,

is there any progress with this requirement?

Many Thanks

https://getsupport.atlassian.com/browse/PSSRV-60906

In addition to that it would be cool to have a global setting and a project level setting that overrules is. With that it would be very flexible but still easy to use for the ones following the default hierarchy.

Hello, please provide an ETA on JPOSERVER-1528

This is blocking adoption within our organization as well.  Project based would solve many problems for us.

This would work well for our program managers, but we are also blocked on adopting because of this limitation. We’ve been using Jira for years now and having to change hierarchy per project at this point is not feasible.

One of our current projects is blocked from adopting Plan because of this limitation.
Is there any hope of having this addressed in the near future?  

I agree the setting should be project based.

I second Nidhi's ask above. When can we get an update on this item. 

thanks, 

Jennifer 

Hi Team,

When can we expect this ?

Please provide us an ETA of the same.

Thanks

Nidhi

That's a great feature which might also be troubling in large Enterprise Jiras:

1. Imagine Admin overhead to configure hierarchy per plan (we have 1500+ active projects in Jira and 25,000 users).
2. Deviations would cause confusion across teams around other teams' hierarchies and disruption of cross-team reporting.

With that in mind, please allow Jira Admins to be able to enable/disable this feature when it's released. Thank you!

Adoption of Advanced Roadmaps is slow because people don't want to be restricted by a global hierarchy. This should be at the project level. Every project is different. If they can choose what issue types they wish to use they should be able to choose the corresponding hierarchy. 

I voted this issue up because I feel it is very difficult to roll this out to a 65k+ company without someone objecting to the proposed Advanced Roadmap hierarchy.  I feel it is essential to be able to roll this out MINIMUM to the template level if not, then at the project level.

This feature is essential for the adoption and creation of good meaningful plans at large scale. We would also, like many many others, appreciate the support for more flexible / multiple hierarchies.

Thank you!

How do we get this moving forward? My company has the same need and not having this capability is becoming a blocker to show the right data in plan supporting answering the right questions. We dont want to create a hack. thanks! 

We have same needs. Different type of internal divisions and levels, 1500+ projects cannot be compatible with just one hierarchy type, but per project/plan. 

Me too, I agree with above comments: this would be a very useful feature...

I agree with all of the above mentioned comments. This is a needed functionality.
It could be so that hierarchies work as schemas in Jira and as Admin you can design a number of them that can be used by the projects in your Jira instance. (or Jira cloud)

I worked with 75 ARTs whereof 12 or so ARTs built up 3 Solution trains. So all 75 ARTs had to ignore the capability level in all create screens and other configurations like the parent field. It would be great to have the flexibility to connect one hierarchy template/schema to a group of Jira projects.

I agree with @Raju NS ... is there any plan to implement this?

Hi, This is very much required feature . 

We have around 290 Jira projects - single Hierarchy configuration affects all other teams.

May I know, are there any plans to implement this?

Hello, are there any plans to implement this? This sounds quite natural to have the ability to apply a hierarchy per project.

We also would rather see a different way for the global hierarchy setup.
It makes no sense to not implement some change to this config setup. I't would make much more sense to have based on project instead of global as we are running several projects of different nature.
We also would like to run both Full SAFe configuration as well as the Portfolio SAFe configuration on the safe server 10000+ users.

@Josh Steckler +1

just to explain the limitation we're facing:

We're trying to implement SAFE (Scaling agile with Atlassian and SAFe) as documented by Atlassian (written by Dan Radigan and two others). 
The problem we see is that when our different departments would need to have different scaled organizations, such as some need Large Solution, and some not, we could not have different hierarchies created for each of them, with just one instance of the Portfolio. As an example in the document, we've Portfolio Epic, Capability, Feature, Epic and Stories. Each one with different Jira Project except for Epics and Stories are at team level project. Instead, in another department, we don't have large solution, that means we need Portfolio Epics, Feature and Stories..

I agree with this, except that I'd say hierarchy per project, not per plan.

This is very necessary. The choice is to either create very generic issue types that lose all meaning from department to department, or allow users to define their levels to be as descriptive and clear as necessary.

Configuring issue hierarchy at global level may work for organizations having project of similar nature and scale, it's not very tenable for organizations with projects of differing nature (Hybrid Agile, Scrum, SAFe, etc) and scale (project, program, portfolio, enterprise).

To support a varied setup, we need the issue hierarchy to be configured at the plan level (rather than at global level).

FYI that ours is a Data Center based setup that services 3500+ projects and number of them have varied configurations.

We need this improvement as well. Organizations have different teams with different needs and they require different hierarchies.

This is incredibly important. I am working with a enterprise that has multiple 10000+ user instances. Having hierarchy defined at the global level is making this an extremely hard sell – The teams were highly interested until they realized that they will not be able to define hierarchy, but rather the IT owners of the JIRA application will have to configure the hierarchy for all teams.

Effectively this is a non-starter: My customer is approximately 4000 users, however they are in a JIRA instance with 10000+ users. They will not have control of the hierarchy relevant to their organization so we are required to pursue other options.