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
Objetive 2: Keep the custom fields as standard as possible
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.