nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How many issue types?

Rubicon Technology

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...

Accepted answers

Nic Brough -Adaptavist-

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.

All comments

Nic Brough -Adaptavist-

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

Rubicon Technology

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?

Joe Pitt

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'

Nic Brough -Adaptavist-

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)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

issue-type