Change of hierarchy - consequences?

[Flavio Petrini]

Dear team,

I just created a custom data type that I would want to have on the same level as the epic. 

Currently I am of course able to link child issues to it, but I can't track it in swimlanes on the kanban board. To do so, it is my understanding that it must sit in the same hierarchy as the epic.

When trying to change it and saving it I get the below message:

This makes me somehow unsure as I don't want to break anything in our Enterprise. 

I still need the epics for all other projects, but I also need my new data type for my project.

Given that I just added my new data type to the Epic Level, and haven't changed the Epic itself, can I break something? 

Is what I am trying to do the correct way to proceed given my needs?

I tried to look for information on the matter, but just get stuff related to creating a bigger hierarchy in "Advanced Roadmaps" that I don't have, not being a premium user (yet).

I'd be glad for any advice.

[Ste Wright · Accepted solution]

Hi @Flavio Petrini 

It shouldn't break the hierarchy - you're not modifying the Epic level itself, just creating a parallel parent level.

But I would recommend testing this in a non-Prod environment first - without Premium to have a Sandbox, this likely means creating an additional instance.

Just a few quick additional notes to take into account:

• To link Child issues to the new Issue Type, they'll need the "Parent Link" field on the screen
• Child issues cannot have both a Parent Link and an Epic Link concurrently - just one or the other
• Epic features will not apply to the new Issue Type - eg. Board Swimlanes, the Epic Panel, etc

^ I'd recommend considering if the new Issue Type is really necessary in this case, or if you could just use the Epic for this.

If you have any further questions, let us know :)

Ste

[Flavio Petrini]

Hi Ste,

A happy new year to you :)

thanks for coming back to me so quickly! Yeah, to make a test I'll have to invent something on a different instance, but who knows, perhaps we'll get Premium one day ;) 

The reason for using a different type is that the field content in this "custom type" is totally different from the epics we use for development, but we'd want to have it on the same level.

Your last point is unfortunately what "breaks it" for me. If the features of the epic would not apply to this new type then in principle all the advantages of having it as an epic are gone, as I can still link stories & subtasks as children of it.

I'll figure something out.

Thank you so much,

Flavio

[Ste Wright]

Hi @Flavio Petrini 

Are Epics and the "Data Type" used in the same Project?

If not, you could consider having a different Screen with a different set of Fields for this - and assign it to the Epic?

Or, have the fields on an Epic, in a separate field tab, so it's "separated" from the standard Epic fields?

Ste

[Flavio Petrini]

Hi @Ste Wright ,

thank you again for the prompt answer.

They are unfortunately used in the same project, but I do like the idea of the "Tab". Haven't thought about it. I'll propose the idea accordingly internally!

Kind Regards,

Flavio