Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Many Issue Types or just a few?

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?


Antoine Berry Community Leader Apr 05, 2019


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.


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.


Log in or Sign up to comment