Custom Fields in Jira - To Create or Not to Create? That is the question
If you are a Jira Administrator, this is a question that you should necessarily ask yourself, not because it is not possible of course, but because as administrators we aim at the maintainability of our Jira instance.
My recommendations when working with Custom Fields are:
Limit the number of fields you define.
Do not duplicate fields.
Don't duplicate field names.
Use generic names.
Avoid human error, autocomplete fields or handle standard option lists for the field when possible.
Use fields contexts responsibly.
And now let me explain why they are important, but let's start with the first:
What is a Custom Field?
Which are their properties?
So, when should we create a Custom Field?
What is the objective?
What is a Custom Field?
There are two types of fields in Jira, System Fields, and Custom Fields. The System Fields are those fields that are part of the field package of any Jira instance: Summary, Description, Version, Priority, Due Date, etc. These cannot be changed significantly, we will only be able to change some minimal aspects of them from the field configuration scheme, for example the screens in which they appear and in all cases, except with Summary, detail whether they are mandatory or optional or whether or not they are hidden on a screen. These fields are not available from the Custom Fields option.
Custom Fields are fields that we can define and customize their behavior. We define Custom Fields so that our Client can record the information he needs and then make use of it, organizing, classifying or generating reports.
There are Custom Fields that are automatically generated by Applications or Products, and their editing and configuration options will be locked. But our focus here are the Custom Fields on which we are going to be able to work completely, that is, the Custom Fields defined by us.
Which are their properties?
Custom fields have a number of properties that will define what data they can contain and how it will be presented and searched. Let's review these properties together:
Name: It is the label that is displayed on the screen to the left of the custom field.
Description: It is the help text that appears below the field.
Default Value: The default value that a field can assume when a new ticket is created. It is important to consider if we are going to use it or not, since we could be recording information that is not relevant, but this topic may be part of another post.
Context: It is a very useful option that we should not abuse. It allows us to generate various Options for a field depending on the combination of projects and issue types. So for the same custom field we will have different options depending on the context in which we are standing (combination project and issue type)
This can help limit the amount of custom fields by reusing them in a different way.
Screens: These are the screens in which the field will appear when a ticket is created, edited, viewed or transitioned.
Search template: it is the mechanism for making a custom field searchable through basic search and advanced search, also responsible for custom field indexing.
Additionally, depending on the type of custom field we are working on, we will have the following attributes:
Options: Only available for Select List, Radio Button, and Check Box types. They represent the values that users can choose from. Example, for the severity field we could have the options: Blocker, High, Medium, Low
User filter: Only available for fields of the user select type, it allows us to define the set (groups or roles) of users among which a user field can be chosen.
So, when should we create a Custom Field?
Theory about best practices in fields creation tells us:
Limit the number of fields, they should only be created when using a System Field is not an appropriate option.
The creation of the fields must be justified, adding fields adds more complexity to the Jira administration tasks.
Whenever possible, reuse custom fields, so it is important that the custom field name is as standard as possible to reduce complexity and simplify reporting.
Do not duplicate field names, Jira allows you to create custom fields with the same name, I have seen instances of Jira with up to 10 custom fields with the same name, even some of these sharing the field type. This can cause big problems. Ideally, these fields should be merged, but if that's not appropriate, make sure to keep the names unique.
Try not to leave room for human error when loading the information, choose the correct type of fields, depending if it's meant to be a number or text. For the last scenario, the Select List fields are preferable to text fields or labels. In this way we will ensure that the reporting is more consistent and the search in JQL more accurate.
What is the objective?
Taking into account these good practices, when creating custom fields we should keep in mind two objectives:
Objetive 1: Keep the number of custom fields to a minimum
Usually when a client needs to add a new field, I ask myself the following questions as a checklist:
Is there no System Field that contemplates or adapts to the load of this information? If and only if this answer is negative, I go to the next one.
Why does the customer need it?
Filter issues of a project, board or queue?
Is this information relevant for decision making? This contemplates automations and transitions, among others.
Will the information be shown in Reports or Gadgets?
Try to work these questions with your client since they aim to solve if the field is really necessary and will allow you to know if it will be used or if it will become a field that no one know why it is on the screen. Once we decide to create it, our next step is to ask ourselves: Is there already a field that allows us to record this information? If it exists, and we did the required work well, we will be fine with Objetive 2.
Objetive 2: Keep the custom fields as standard as possible
There are two key aspects to consider here, and they require great skills on the part of the Jira Administrator
Uniqueness and generality of the Custom field.
This is where you will have to bring out your “soft skills” since you will have to explain to your client the importance of the field being unique and generic. We already talked about the need to always check if a field with the same name already exists before creating it, but why is it important? if the field already exists and we add another like it, JQL lookups can become a headache.
Also do not create fields with the same name as a System Fields. For example, having two fields named "Resolution" can be confusing. Using a generic name for the field will help us reuse it. If the client asks us to create a field called “Bug Category”, we might suggest create a custom field called “Category”, and we could use it later in other circumstances with a different context. The same would happen if the client asks us to create a field “Story End Date”, in this case we could use the System Field “Due Date”.
To give more clarity to the client's need, we can then use in the Field Configuration option, the description of the field that provides more information about what is expected to be loaded in that field.
Use all the functionalities associated with a Custom Field.
This is where our “Hard Skill” or technical knowledge about what Jira allows us to do with a custom field.
The first thing we'll need to do when creating it is decide on the type of custom field we're going to generate, remembering that not all field types are created equal when it comes to reporting. Structured fields such as single select and multi-select lists are particularly effective as the user has a limited number of options to choose from and therefore there is a known fixed set of options to search for and display in your reports. On the other hand, text fields are less structured and can only be searched using the contain (~) operator, which means they are much less useful in reports, as people don't always enter data correctly or as expected by the JQL query used in the report.
The same could happen with dates. Which one should I select Date Picker or Date and Time Picker? It depends what we are going to use it for, usually I only use “Date and Time Picker” when this field will be registered automatically and when I am going to use it to make precise calculations. Example an automation that calculates the time between two dates.
Do you have a different criteria to implement what is presented? Tell us in the comments
It is very common that there is more than one way to do things with Atlassian tools and we would love to discover other ways to solve them.
We hope you enjoyed reading,
Until next time.