How many custom fields are too many?

When do custom fields start to impact performance? We have had new administrators add fields and beyond the OCD factor, is there a tipping point? Are there any best practices around adding custom fields?

2 answers

1 accepted

1 votes


I've been in the ecosystem for a little over 5 years. I've seen small jiras, big jiras, ugly jiras, and beautiful jiras.

I currently run three Jiras:

  • 10,000 User License (~6000 users)
    • 600 Projects
    • 750,000 Issues
    • 1,900 Custom Fields
    • 450 Statuses
  • 2,000 User License (~2000 users)
    • 10 Projects
    • 3,500 Issues
    • 25 Custom Fields
    • 20 Statuses
  • 2,000 User License (~2000 users)
    • 1 Project
    • 40,000 Issues
    • 30 Custom Fields
    • 10 Statuses

The problems with the number of custom fields are largely overblown. While I agree that less is more and you should be extremely judicious about how/when/why you create custom fields, in my opinion, they stem mainly from usability problems. The issue navigator, plugins, the Custom Field Admin screen, these tools were NOT made to work with 1,900 Custom Fields. 

In a system with 1,900 fields:

  • The Columns feature of the Navigator lets you search through fields, but it only lets you view the first ~10 fields: Any beyond that are LITERALLY INACCESSIBLE. 
  • Some plugins or field selections take 30 seconds to respond
  • Lots of complaints about confusing field names
  • The Custom Field Amin screen takes 45+ seconds to load
  • Field Configurations take 1+ minutes to load
  • Duplicate fields are bad!

Take the advice with a grain of salt, but you should be careful to vet use-cases before creating fields. Do you really need it, are you ever going to query on it, report on it? Why can't they make use of Labels or another field? Why can't they use one of the existing Custom Fields?

When you do create a field, choose the TYPE extremely carefully and make sure you use a widely generic and applicable name.

Peter DeWitt Community Champion Sep 28, 2017

Nice write-up Steven.  I have also worked in systems with anywhere between 100 and 1600 custom fields.  My rule of thumb is always: less is more.

Steven Behnke Community Champion Sep 28, 2017

Agreed, whole-heartedly. Custom Fields should represent a little use-case. The question could be posed as:

"As a Company, anytime we want to track this data, we'll put it in a field called <Blank>."

This dramatically changes the Name, the default Description, Type, and choice of Options in the default configuration scheme or a default value. This implies you should

  • Use a generic, approachable, short name
  • Only set a default description if it's 100% necessary
  • Use widely applicable options
  • Almost never a default value in the "global configuration scheme" for that field

If you abide by a few reasonable rules, you'll only be limited by the use-cases needed by the teams in question! And further, they'll be sharing datasets which is the whole point of a unified system like Jira.

Thank you for the detailed answer!

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,774 views 11 18
Join discussion

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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot