Time to Decide: What to do with all those Jira Custom Fields

In a previous article, Rachel Wright outlined a process for auditing Jira custom fields.  If you’ve completed this process, you now have an idea of all of the custom fields in your Jira instance.  Finding out what you have is an important first step.  Next you need to decide what to do with them.

If you haven’t already, log your information into a spreadsheet, a Confluence page or use the free Jira Custom Field Audit worksheet.  At a minimum, you will want to collect the following information:

• Name – The name of the Jira custom field
• Type – Knowing the field type can be useful in determining if the field can be merged
• Description – What the field is for
• Created by – Was the field created by Jira, by a person or by a plugin/app?
• Used by – Who is or has used this field?  Which Jira projects?
• Currently in use – Is anyone using the field now?

I found all my custom fields.  Now what do I do with them?

Follow the recommendations Rachel describes, or try the SQL queries provided by Atlassian.  Once you’ve filled in the above information, you need to take the next step – engaging with Project Admins, business owners and other users to find out if and how the fields is being used, and to determine if another solution might work just as well or better.  Ask questions such as:

• How do you use the data in this field?
• Do you query the field? (You can verify this by checking to see if the fields is included in any filters.)
• Do you report on the field?
• Does anyone remember how you handled this data point before you had the custom field?

As you talk to business owners, users and project admins, it’s important to be clear that your aim is not to take needed functionality away from them. There are many ways to reduce custom fields without losing current functionality.  After you’ve completed your research and your conversations with business owners, you can recommend one of the following options for each custom field:

• Keep it
• Merge it with another Jira custom field
• Substitute it with a field on ProForma form
• Aggregate it with other data into one field
• Retire it
• Delete it

We’ll discuss how to do each of those things in a future article.  For now focus on deciding what the future of each of your custom fields should be.

When to Use Each Option

Keep it
Don’t change a thing.  The field is necessary just as it is.

Merge it with another Jira custom field
Your Jira instance may have accumulated multiple custom fields that are essentially the same (for instance, multiple sets of start and end dates). These can be safely merged together into one field that has a generic name.

Substitute it with a field on ProForma form
Many data points are needed in order to handle a request (service desk projects), or track information that is important, but rarely queried or reported on.  You can still collect specific, structured information without custom fields, by collecting the data on a form.

Aggregate it with other data into one field
Aggregating is another good option for data that is collected for purpose of providing a service, background info, etc., but that is only occasionally queried or reported on.  This involves collecting the data on a structured form, then storing the data from multiple form fields in one Jira field.

Hide it
You can hide custom fields that were used in the past, but are no longer necessary.  This allows you to preserve the data while decluttering your screens.

Delete it
Delete fields that are not being used and that do not contain any data that needs to be preserved.  It’s recommended that you not delete custom fields that were created by Jira (and in many cases Jira won’t let you).

Add a Recommendation column to your spreadsheet and log the selected option for each field.  You now have a plan for each of your custom fields. Watch for the next article in this series, where will discuss exactly how to apply the above options.