Managing custom fields in Jira effectively

Overview

The ability to set custom fields makes Jira a powerful workflow management tool, allowing you to create highly specific objects for modeling the way your organizations work. However, like all good things, too much can be detrimental to Jira's performance and administration. Here, we explain how using custom fields affects Jira's performance; we also provide several recommendations on its proper use and optimization.

Too many custom fields can slow down your instance

The response time of any action that requests or processes custom issue details (viewing, searching, creating/editing issues, and adding comments) is affected by the raw number of custom fields in Jira. Our scaling tests for Jira 7.7 revealed as much: 

When we tested ¹ different user actions on Jira instances with 1400 and 2800 custom fields, the latter showed significant differences in response times for Add Comment, Create Issue, and Edit Issue. Considering that users spend most of their time on Jira performing these three actions, it's clear that you need to pay close attention to the number of custom fields in your Jira instance. 

We also tested the same set of user actions across eight other Jira instances, doubling a different data point each time. The following table shows aggregates of all average response times, for all actions in each test:

This graph suggests that of the eight data points we tested, the number of custom fields had the greatest effect on average response times. 

Identify and clean up unused custom fields

Here's three strategies for reducing custom field bloat in your instance:

1. Delete any unused custom fields. 
2. Merge custom fields that see very little use.
3. Limit the scope of the custom fields to specific projects context. 

Before removing or consolidating any custom fields, discuss them with Business Owners and ensure that your changes are tested in a QA environment before rolling them out to production. This is a time-consuming process, but you need to be careful so that no critical data is lost. 

Custom fields usage

In Jira Data Center 8.16 and later, the Custom fields page includes new columns that show the usage of your custom fields—how many issues are actually using them and when was the last value made. You can sort by these columns and use additional filters for value updates to quickly find good candidates for deletion. For more info, see Analyzing the usage of custom fields.

Jira's built-in custom fields optimizer

You can start the process of cleaning up your custom fields through Jira's built-in custom fields optimizer. This feature lets you scan your instance's custom fields and highlight the ones you can optimize. See Optimizing custom fields for more information.

SQL Database queries

If you need to take a more detailed look at your Jira instance's custom fields, use the following SQL queries.

select count(*), customfield.id, customfield.cfname, customfield.description
from customfield left join customfieldvalue on customfield.id = customfieldvalue.customfield
where customfieldvalue.stringvalue is null 
and customfieldvalue.numbervalue is null 
and customfieldvalue.textvalue is null
and customfieldvalue.datevalue is null
group by customfield.id, customfield.cfname, customfield.description;

select customfield.id, count (*)
from customfield left join customfieldvalue on customfield.id = customfieldvalue.customfield
group by customfield.id having count (*) < 5
order by count (*) desc

select field.id, field.cfname from customfield field where field.cfname not in (
select item.field from changeitem item
JOIN changegroup cgroup ON item.groupid=cgroup.id
where item.fieldtype='custom' and cgroup.created > 'YYYY-MM-DD'
) and customfieldtypekey not like '%com.pyxis.greenhopper%'
and customfieldtypekey not like '%com.atlassian.servicedesk%'
and customfieldtypekey not like '%com.atlassian.bonfire%'
and customfieldtypekey not like '%com.atlassian.jpo%'

select id, entitytype, entityid, username, to_timestamp(lastviewed/1000) as lastviewed, data from userhistoryitem 
where entityid='customfield_10001'
order by lastviewed desc;

select * from customfield 
where customfieldtypekey = 'com.atlassian.jira.plugin.system.customfieldtypes:select';

select * from searchrequest where reqcontent like '%Field Name%' or reqcontent like '%10001%';

select * from jiraworkflows wf where wf.descriptor like '%customfield_10301%';

SELECT
cf.id id,           
to_char(min(ji.created), 'YYYY/MM/DD'),
to_char(max(ji.updated), 'YYYY/MM/DD'),
count(distinct(ji.id))
FROM CUSTOMFIELDVALUE cfv
left join JIRAISSUE ji
on cfv.ISSUE = ji.id            
left join CUSTOMFIELD cf
on cf.id = cfv.customfield            
GROUP BY cf.id
ORDER BY cf.id

SELECT distinct
customfield.id from customfield
join FIELDSCREENLAYOUTITEM
on FIELDSCREENLAYOUTITEM.fieldidentifier = CONCAT('customfield_', customfield.id)
join FIELDSCREENTAB
on FIELDSCREENTAB.id = FIELDSCREENLAYOUTITEM.FIELDSCREENTAB join FIELDSCREEN
on FIELDSCREEN.id = FIELDSCREENTAB.FIELDSCREEN;

Atlassian Marketplace plugins to identify/remove custom fields

• Jira Command Line Interface (CLI): Includes a prebuilt 'removeCustomField' function

• Configuration Manager for JIRA: Great for identifying and resolving custom field conflicts. See Duplicate Custom Fields (Botron Software site) for more details.

• Admin Tools for JIRA: Features the ability to identify which custom fields are currently in use and clone custom fields.

• Cleaner for JIRA: Lets you to list Custom Fields, how they are used, and delete them if necessary.
• Custom Fields Usage for JIRA: Lets you view Custom Fields with their name, type and description. It will also mark Custom Fields that were never set in any issue, and you can delete them in one click.

Set up governance around custom fields

Once unused or rarely used custom fields have been identified and removed successfully from an instance (or merged), set up rules and guidelines for creating new custom fields in the instance. This will help establish a disciplined approach, helping prevent it from affecting your instance's performance. Establishing governance around Jira customization is useful in balancing the growth of the instance with its ability to serve the needs of its users.

A few things to keep in mind here:

Evaluate requests for new custom fields: When users request new custom fields, establish a process for vetting the necessity of the request. Meet with the users to interpret their requirements for the fields and figure out if an existing field can be repurposed or if a field is needed at all. 

Verify the purpose of new custom fields: Ensure that the information captured by each field serves a justifiable purpose. If the data is not used to work on the issue, or for reporting, then it is not needed. Track the number of custom fields actually being used on a quarterly basis or as frequently as it is practical in your organization.

Establish and share a governance policy: Create a clear and definitive set of regulations that establish how new objects such as custom fields, workflows, and other customizations are added to Jira. 

Get executive backing Share your governance policy with relevant managers and executives at your organization and emphasize the need for their support in keeping Jira running smoothly. Be ready with facts to substantiate your policies and show how the lack of governance affects the performance of the instance and ultimately impact the end-users. You can even show the test results from this article.

Other recommendations

Some other useful Do's and Don'ts for managing custom fields  are summarized below:

DO

• • • Reuse existing fields when possible.
    • Make field names as generic as possible.
    • Give your custom fields useful descriptions, including examples of valid values.
    • Format custom fields consistently (for example, capitalization). Whenever possible, keep them consistent with Jira defaults.
    • Be careful of trailing spaces and other non-visible characters added to custom field names. These will make using scripts harder.
    • Err on the side of flexibility. For example, a multi-select field is more flexible than a single-select field.
    • Translate custom field names for your users who are using a different language pack.
    • Know how and when to use custom field contexts.
    • Use the Where is my field? feature to track down missing fields.
    • Have a governance policy and make it easy for users and executives to find.
    • Use custom fields contexts appropriately. For example, avoid using global context when a custom field is only being in used in one project. 
    • Avoid setting default values for your custom fields whenever possible.
    • When creating custom fields with a drop-down list, try to minimize the number of options available. 

DON’T

• • • Don’t create custom fields with duplicate names. This can lead to administration mistakes, reporting issues, and custom script errors.
    • Don’t create option fields that have to be updated frequently. For example, a select list with usernames will quickly become outdated as people’s roles change. 
    • Don’t add the option value None. This option already exists when the field is made optional and adding it to the list makes reporting harder.

We're here to help

This article features advice typically provided by Atlassian Advisory Services to customers when custom field use starts affecting performance. Advisory Services can provide strategic guidance to help you choose the right methods to manage your custom fields or even mitigate other performance problems.

Our Premier Support team performs health checks by meticulously analyzing your application and logs, to ensure that your application's deployment fully meets the needs of your users. If the health check process reveals any performance gaps, Premier Support can recommend possible changes to your instance.