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

what are the options for consolidating different issue types to one issue type for a project?

vcatl2020

Our Jira software project includes a Project with bunch of issue types and each having a specific purpose with reference to supporting applications in our company. There might be few shared fields across these issue types along with unique additional fields that are relevant to support application.

There is a default field configuration and unique workflow for each issue type, now looking to revamp the process and consolidate all into one new issue type. This way it is standardized for jira users to be able to submit their requests or issues and the ticket lands in a single queue where the dispatcher analyzes ticket info then send it over to the relevant support group.

Question for experts is that would it be possible to consolidate to one issue type and what considerations should be taken into account when working on such setup in a Jira project?

Accepted answers

Joe Pitt

Yes, you can create a single issue type, however I don't recommend it. By consolidating everything you will:

1. End up with MANY fields that aren't relevant to either the user entering it or the people working it. It will just be clutter on their screen

2. Usually different issue types have different required fields upon creation. You would end up requiring fields irrelevant to the actual issue. You would need to have the user put in N/A in a text field or add it to a select list. This would just frustrate the user in my opinion

3. Most issue types have a distinct workflow. In order to make a workflow that is usable you would need to put in many conditions to make the workflow usable. Otherwise you would go through many useless steps.

You can still have multiple issue types and they can all be assigned to the project leads queue and they can reassign them. If I don't use components, that is the model I use.

All comments

Joe Pitt

Yes, you can create a single issue type, however I don't recommend it. By consolidating everything you will:

1. End up with MANY fields that aren't relevant to either the user entering it or the people working it. It will just be clutter on their screen

You can still have multiple issue types and they can all be assigned to the project leads queue and they can reassign them. If I don't use components, that is the model I use.

vcatl2020

That totally makes sense as I also see that single issue type complicates everything. The problem with current multiple issue types is that most people doesn't know which one to pick and ends up in black hole leading to poor customer service, churn and unwanted escalation noise. This is part of training and no user guide related problems on our side.

To cut through, if we have a single issue type for people with bunch of generic fields that accommodates their needs then it goes to a Level 0 queue owner, who reviews and corresponds back with reporter to ensure their ask is reported well, understands to which business it would need to go out for next actions. Either Level 0 person changes the assignee to relevant business owner or creates a subtask under this master single issue type form capturing the key details and assigns the subtask to relevant owner. This would facilitate the reporting and ease of managing with single issue type.

Again this is still in thought process and trying to understand the pros & cons better by setting up this model from Jira experts in Atlassian Community. Any better thoughts & suggestions are open and really appreciated. Thanks!

Joe Pitt

Maybe you should rethink if you actually need so many issue types. Another option would be to have one issue type with the bare minimum of fields required to triage the issue. After it is reviewed move it to another issue type and reassign it to the reporter for more information and give them a transition that returns it to you with required fields in the transition for more information.

vcatl2020

Yep, that's the plan for keeping the issue type more generic and simple and also looking clean up the cluttered issue types first. Moving it to another issue type meaning reusing the same issue type that we currently use, correct?

Also, does it matter if the new simple issue type is created in the same project or any recommendations that it needs to be in a new project altogether?

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