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?
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:
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:
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.
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
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:
I recognize the need to review these 2k plus custom fields and determine if they can be deleted, reused or reconfigured.
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...
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!
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