Jira cloud issue type quantity limits

[Rolandas Jančauskas]

Maybe someone could answer if there are any limits on the amount of Jira issue type per project?

[Joseph Chung Yin · Accepted solution]

@Rolandas Jančauskas -

There is no limitation on how many issue types that you can have within one project.  However, the best practice that I know of is less is better.  Generally keeping the issue types down to less than 10 for a given project is preferred.  Just put yourself as a user of a project - having too many issue types to choose from when creating issues tend to be confusion.

Lastly, issue type management should also be handled at the system level first then push down to the project level.  You should avoid creating too many issue types just because users wanted.  Ideally, sharing existing issue types are the best way to management.  You need to establish a common standards to make your Jira mgmt simpler.

I also agreed with others comments.  Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

[John Funk · Accepted solution]

Hey Rolandas,

We have more than 100 so you are probably going to be good. 

[Dave Mathijs]

@John Funk More than 100 issues types in 1 scheme on single project?

[John Funk]

Yep - mainly is used for metrics and reporting. We do a LOT of various types of content - video, audio, blogs, social posts, emails/journeys, various types of development, etc. 

[Chris Thomas]

I don't know your use case but if all you want are issues with different fields but the same workflow, you can use the new Jira Forms feature to make different forms for your needs.

For example I have one issue type that supports over 20 different departments required fields by using a single form. By using Sections that hide each department has it's unique set of questions.

[Sarah Elmer]

I have a project with well over 100 Issue Types with no problem. I know it sounds like a lot, but it's quite functional for what it's needed for.

[Dave Mathijs]

Over 100 issue types?!  But why? :-) Curious about your use case.

[Dave Rosenlund _Trundl_]

+1

[Sarah Elmer]

Due to the type of business we are in and the clientele involved. Not for direct IT operations. We have different departments that use JIRA extensively. 1) IT (products based) and 2) Client Services (client based). All other departments are based off these 2 main departments and JIRA usage. The industry we are in does not allow us to get direct input from clients via outside sources due to laws and regulations; therefore, the Client based projects deal with input from clients and their needs/requests via direct email, chats, etc. To better control and report, clients are individual Issue Types. Hope this makes sense.

[Carol Low]

hey @Sarah Elmer

thank you for sharing - also very curious to know if you vary the config/workflow for each issue type?

[Sarah Elmer]

Sorry for the delay. I had major surgery on the 20th. 99% of the Issue Types are on one workflow. The few left over are on a different one. So only 2 workflows involved. Hope this answers your question :)

[Dave Mathijs]

@Rolandas Jančauskas I'm not aware of such limitation, how much issue types are you thinking about?

[Mike Rathwell]

As others have commented, I am not aware of such a limitation but it seems monumentally unworkable in practice. Even just the select list would be monumentally unwieldy not to mention confusing for users.

When I see this, this feels a lot more like a handful of issue types but with some other select lists (and do keep those mercifully short as well) for the granularity. Note, also, if you have enough granularity that you pose the question, it is entirely likely that issues will be entered with the wrong information. Changing a select field is rather easier than moving an issue to a new issue type.

Finally, this question also makes me feel like the need you are trying to solve is being over-complicated. When you try to codify for that many items, it starts to look/feel like you are coding for exceptions rather than the 80/20 rule and setting yourself up for a waking nightmare not that far in the future.

[Aaron Geister]

I could agree more with @Mike Rathwell

It seems the more we customize the more we make work for ourselves. I have seen some projects with well over 50 - 100+ but then I ask myself how do they keep track of it all. How do users even know what to add and why so many issue types. 

I am a big believer in less the better.

[Sarah Elmer]

In most cases, you are correct - less is better - and we follow that philosophy whenever possible. But for our client-based usage it actually makes it easier instead of making custom fields, etc. We started using JIRA when it was designed strictly for IT use only and decided to make it usable in multiple departments for company-wide use (IE HR, Operations, Facilities, Training, etc). For Client Services we just open a ticket, type the code (each client has a code) and it's done. Reporting is simplified. If set up correctly from the beginning, it's completely usable and user friendly. Teaching new employees on the system is a breeze.

[Aaron Geister]

@Sarah Elmer I also agree that if you have it set up correctly more might not be to bad but it does have to be configured in a good way so that its easy to use for the client/customer.