You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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
We have more than 100 so you are probably going to be good.
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.
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.
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.
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.
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.
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.
Recommended Learning For You
Level up your skills with Atlassian learning
Configure Jira Software, Jira Core, or Jira Service Management, including global settings, permissions, and schemes.
Managing Jira Projects Cloud
Learn to create and configure company-managed projects in Jira Software and partner effectively with Jira Admins.
Managing Permissions in Jira Cloud
Sharpen your skills at configuring and troubleshooting permissions in Jira Cloud with this free course.