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

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage
Highlighted

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

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

Comment

Log in or Sign up to comment
TAGS

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you