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?

3 answers

1 accepted

4 votes
Accepted answer


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.

We are running an Internal JIRA Instance (Core + Software) with 226 projects and 2,100+ custom fields.  Several of these projects are of type "Business" that are being used in day to day operations.

What contributed to the high number of custom fields is the implementation of Excel forms that used to be manually filled by team members. 

I am now anxious that many teams are requesting for the same "Excel form-to-JIRA" implementation that the number of our custom fields will further increase.

Any thoughts on how to address this?



Question all the fields, every time. 

Why are they different to fields that already exist? 

What report relies on them so that they have to be separated out and can't be done in simple text?

Do you really have 2,100 items that are all reported separately? 

I suspect you'll find 99% of them are useful to 1 or fewer people, and those people probably aren't using the reports any more.

Thanks Nic.  I am developing a JIRA Governance Guide for my (internal) clients and have found these useful articles as my reference materials:

  1. Custom Fields and JIRA Performance
  2. Configuring a Custom Field
  3. Managing Custom Fields in JIRA Effectively
  4. How Many Custom Fields are Too Many (this discussion)

I recognize the need to review these 2k plus custom fields and determine if they can be deleted, reused or reconfigured.



Great Advice.


These are the "unwritten" rules :P

Thank you for the detailed answer!

0 votes
Joseph Pitt Community Champion May 17, 2018

Where lots of people get into trouble is they allow too many people to create fields and as already mentioned create new fields with very similar or the SAME name. 

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,417 views 15 19
Read article

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