Best Practices for Adding New Jira Fields

I recently came across a Jira instance where there were multiple fields of the same type with slightly different names. It appeared that every time a user would request a new field, the Jira Admin would add the field, no questions asked. You may ask yourself, why is this a problem? Why not create the fields users need to process their issues? Those are great questions, and I'd be happy to explain!

The short answer is, users don’t always know all of the available fields, and may ask for a field that's a duplicate of another. Blindly adding fields simply because it was asked for can quickly lead to needless and redundant fields that make it more difficult to manage. Imagine trying to add a field to a screen and you come across “location”, “location.”, and “location*”. What a pain it is to have to dig into which exact one to add to the screen, which is correct, and which might be redundant. Likewise, performing a search on the field will then also become confusing for users.

Learning from clients whose Jira custom fields had become difficult to manage because of redundancy, I put together a list questions I ask to assess new field requests:

Is there already a field that they can re-use? 

I’ve learned, more often than not, there is already a field that can be used for the desired purpose. General users don’t have access to the custom fields page that Jira Admins do. They may not be a part of a project that already uses the field they are asking to create, so they do not know it exists. Or perhaps, they believe the options listed for a dropdown list can only be changed with a new field. As Jira Admins, we know that a custom list can be created based on the context of the fields.

What is the purpose of this field? What type of data will it collect?

Asking this question allows me to determine the type of field the user may need. It also allows for determining if the purpose of this field can be met with another field or function that is already in the Jira instance. A recent example is a request I received to create a field named “analyst,” and to create an automation rule so that the analyst field is always auto-populated with the assignee on the ticket. I explained that it makes no sense to create a field when the assignee is always going to equal the analyst. They agreed and we decided no to add the new field.

After I have determined a field does not exists to meet the users requirements, then I continue to assess if the field needs to be created:

What would be the business value of the new field? Will the new field be used by multiple users or teams across the organization?

These questions help determine if the field will provide any value across the organization. There have been times where I get a user request for a field that is intended to be used solely by that specific user. The field would not provide any value to their direct team or organization. When building out custom fields, it’s important to get buy-in from the team the field will affect. If the field will not provide any value for the team or organization then I generally do not proceed with creating the new field and look for alternative solutions for the user instead.

Will you search or filter issues based on this field’s value? Will you need to run reports based on the values of this field?

These questions help in determining business needs and the type of Jira field to use, should you create it. If the field request is for a JSM Cloud project and no reporting needs to be done, then you may consider using a form to collect the information instead of creating a new field. Likewise, depending on the type of reporting that needs to be done, certain types of fields may not work. For instance, you can not perform history searches on all field types.

To sum it all up, here are general rules to follow when creating new fields:

• Only create a new field when a system field, another custom field, Jira Form, or a third-party app cannot satisfy the requirements needed.
• Users should provide justification for new fields. At a minimum, the field should benefit the direct team.
• Name the field in a manner where they could be re-used for additional purposes.
• If possible, use the field context to customize fields on a project-by-project basis.
• Field names should be unique. Technically “location” and “location.” are unique, however, it makes it difficult to determine which one you actually need to use when adding to a screen or performing a Jira search.