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; } } }

Add custom field to standard issue type or create new issue type?

Christian Strempfer

I'm looking for best practices in regard to customization of issue types.

In an enterprise setup with 100 teams that are using the same Jira instance and want to use custom workflows and fields, how show I handle the customization requests?

Should I create new issue types for every project? Would that affect the performance (custom issue type versus more custom fields for everyone)?
Will all features still work with custom issue types? Especially the Epic filters on the Agile Boards.
Dependent on your recommendation, will that work when giving workflow administration rights to project admins?

Comments

Nic Brough -Adaptavist-

Welcome to the community!

It is mostly harmless to create loads of issue types, technically. There is some overhead, but it's utterly trivial compared with other factors. The human down-side of many types far outweigh any technical considerations. Specifically:

Your admins will struggle with vast lists of similar types. This alone would waste more time than the overhead load on your server!
People are always going to want to share issue names (how many projects are going to want to use the words "bug", "feature" or "task" - there's no chance it's only only going to be one!)
There can be only one Epic type that behaves as an Epic - no custom issue types will behave like Epics

And on your last question, yes - the project is the main thing that controls configuration via the schemes, but it goes down to issue type by project for some things. For example, you can say "Bugs in project A use workflow 1 and Bugs in project B use workflow 2" - the selection is by project and issue type, giving you maximum flexibility and yes, this works perfectly for granting workflow rights to project admins.

The usual recommendation is to keep the list as clean and simple as possible. Create the types you need and share them, there's no reason not to.

Christian Strempfer

Hi Nic,
the alternative would be to have a lot of custom field on the same issue type. Wouldn't that be equally confusing? How would that affect the performance?

Nic Brough -Adaptavist-

That's annoying for the end-user - presenting them with fields they don't need on an issue type is not friendly, and a good admin will keep the fields as simple and clear as possible to save them time!

On a technical level, many fields is one of the ways you can cause issues. Performance is quite a complex thing in Jira, but each and every different field causes overhead you would want to avoid if you can. But you can minimise that by limiting the context of fields. (On this one the short answer is "a field that only exists in project X on issuetype Y is more performant than a global field")