Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

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


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?

1 comment

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.

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?

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")


Log in or Sign up to comment