Many Issue Types or just a few?

[Derek Fields _RightStar_]

I have inherited a JIRA Service Desk project in which the prior admin configured essentially a one-to-one match between Issue Type and Customer Request Type. All of the Issue Types share the same Workflow, Screen Scheme and Field Configuration. In other words, there is nothing different about them from the Agent perspective. 

My inclination is that remove them and have a single issue type that is reused for all Customer Request Types. This would work without any problem. However, I understand that initial motivation, which is to make it easy for the Agent as well as reporting to differentiate between the types of tickets that are raised. While we can look at the Customer Request Type, it is painful to have to do comparisons based on the internal value rather than the text value.

As a general question, what are the pros and cons of using multiple Issue Types that represent different types of Issues even though the workflow and fields are the same?

[Paul Mata]

I agree with Antoine, the reason we use different issue types with the same workflows/screens/fields is simply for metrics tracking. Working within a "cross functional" workflow, we have the epics assigned to the team lead and then they assign the tasks to the people on their team that are responsible for each piece. Each user is able to make sub-tasks as well, to request something from their support teams.

We use different issue types for each task and sub-task to allow detailed JQL queries to be written to present only the issues that are pertinent to each member of the team.

You could probably still do some filtering based on a custom field, but having the issue types allows for future growth.

[Antoine Berry]

Hi,

I think having different issue types is good for reporting and assessing the activity (having metrics linked to each issue type...). That being said you need to find a fine line to justify an issue type over a select list for example.

Also, different issue types allow to independently update the workflow in the future (you might need to assess your future needs). That being said I have worked in contexts that have a different workflows for each issue type, and other that have different issue types for a single workflow.

I would not assert that one is better. It depends on your needs.

Antoine