How many custom fields are too many?

[Sharon Connell]

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?

[Steven F Behnke · Accepted solution]

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]

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 F Behnke]

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.

[Doods Perea]

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?

Thanks,

Doods

[Nic Brough -Adaptavist-]

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.

[Doods Perea]

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.

Regards,

Doods

[Gezim Shehu [Communardo]]

Great Advice.

These are the "unwritten" rules :P

[Maria Angermaier]

Hi all, 

we have currently almost 500 cf and are trying to set up a guideline Custom Fields and JIRA Performance which was recommended by Atlassian however I had difficulties to find any inspiration online how it could look like. Any inspiration? 

I know the Do´s & Don`t´s however from an admin perspective however I need to create a policy I can share with users 

Thank you in advance

[Joe Pitt]

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. 

[Sharon Connell]

Thank you for the detailed answer!