How many issue types?

Hi, newbie to the JIRA core product so apologise if this has been asked before but I haven't come across a good set of "best-practices".


I'm setting up a project to manage "approvals" for our business. These might be purchase approvals, system access approvals, data access approvals etc. The process is sort of the same although the approver could typically different in each case and I'd like to be able to group them by "type" for monitoring.


Would this generally be managed by creating lots of issue types, or using components within an "approval;" issue type?.. or something else...

1 answer

1 accepted

2 votes
Accepted answer

Either types or components, or even a custom field would do it.

I would ask a slightly different question - are these things going to behave in the same way within the project?  If they're identical, then keep it simple and use a simple "approval" issue type, and components or a custom field.  If you need different workflows, or fields, then use the issue type (config hangs off project and issue types).

What you've described though with the "different approver" does feel like a single issue type with components.  This is because you can apply a "component lead", and have them automatically assigned new issues when one is created with their component.  Even if your process is more "component lead reassigns it to the right authority", you'll still have a nice simple process and no proliferation of issue types.  And you'll be free to use different issue types in the same project that then behave differently to approvals.

Thanks for the answer. I suppose these could also all be deemed "IT change requests" and then I could use a required field for the type? I'm happy to raise issues/tasks myself and then assign to an approver manually (or use @mentions?). That would be fairly standard.

I guess I'm really asking is will I regret being so generic down the line (i.e. doing all change requests as one issue type all under one project), or might I be able to split them out later if required? i.e. is it better to start more generic and avoid proliferation whilst getting used to the product?

Joseph Pitt Community Champion Sep 26, 2017

You can always start with one and then decide if you need more.  I've often implemented a project simply.When the users get used to JIRA they often see how it can be enhanced to provide more data or granularity. If you make it too complicated they may avoid using it. And sometimes just requiring them to pick an issue type is 'too complicated' 

Indeed, yes, they're all "IT change requests", and yes, I'd make the "component" field mandatory so that your users have to fill in at least one (and hopefully get it right).

I'd probably set up the components with leads, and aim to choose leads who are going to be the main approvers, then a little education on "if it's not you to authorise this, just assign it over"

If that doesn't end up working for you, then it's not hard to undo.  Add some new appropriate issue types, then use "bulk edit" to identify the old issues with component = x and move them to the new issue type (keeps your data clean this way)

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,653 views 18 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you