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

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

5 votes
Answer accepted


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 Leader 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 Leader 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.



Like # people like this

Great Advice.


These are the "unwritten" rules :P

Thank you for the detailed answer!

0 votes
Joe_Pitt Community Leader 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 in Jira

Keep your team in the loop with Team @mentions in Jira Software!

Hi everyone! My name is Jenny, a Product Manager at Atlassian. After launching Team @mentions in Confluence, we heard a lot of positive feedback from customers that they love how easy it is to @men...

222 views 4 12
Read article

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