What is the best practice for when to create issue types to avoid having a flood of issue types?

[Jesse Ontiveros]

In our first Jira instance, we created whatever issue type was requested, which resulted in having thousands of issue types. This caused some confusion later for agents with trying to figure out what issue type needed to be used, and probably impacted us negatively in other ways. In our new Jira instance, we are trying to follow best practices for when to create an issue type but need with understanding what is the best practice for when we should create issue types. 

[Nic Brough -Adaptavist-]

Train your 3-7 admins to

• respond with "no" when someone asks for a new issue type
• demand generic, reusable names for them

Not because you don't want to do it, but to provoke the conversation as to why.  Get the user to justify the benefits of the new issue type, over sharing an existing one.

[Murilo da Costa]

genius.

[Brant Schroeder]

Jesse,

  We have implemented general issue types that can be used by lots of different request types and ask our service desk admin's to utilize those categories when creating request types.  Since an issue type can have many request types associated with it this works well.  We only allow for exceptions when additional workflows are needed since an issue type can only have a single workflow.  This helps us keep issue types to a manageable level.  Example below.

General Issue Types:

• Task
• Sub-Task
• Service Request 
• Service Request with Approvals
• Incident
• Change
• New Feature
• Bug

Custom Issue Types

• FDM
• HR Request