Why we love (and hate) Jira custom fields: an ultimate guide

Custom fields are one of the most beloved features of Jira. They’re also one of the most misunderstood and misused.

When Jira custom fields are used well, they turn Jira issues into excellent communication tools. They also enrich your data for better and faster filtering and reporting.

When they’re used badly, they lead to cluttered Jira instances packed with fields you don’t need and overengineered issues that confuse users.

In this guide, we’ll explore:

• what custom fields in Jira are, and why they’re useful
• how to create custom fields in Jira
• best practices for using Jira custom fields, and how to avoid “custom fields hell”
• what to do if the out-of-the-box custom fields aren’t enough

What are Jira custom fields?

When I started using Jira, I didn’t have the faintest clue what a custom field was for ages. It was one of those techy terms that non-technical users like me try our best to ignore.

Eventually I realized they’d been staring me in the face the whole time.

First, what are fields?

Fields are just the bits that make up a Jira issue. The summary is a field. The description’s a field. The issue type, status, assignee, priority, due date, labels… all fields. Anything that you, the user, can enter on an issue is considered a field.

System fields versus custom fields

There are two types of fields in Jira. There are system fields which come built-in and can’t be customized, changed, or removed. These include the summary, description, issue type, and due date.

Then there are custom fields, which means you define what they are, how they look, and how they behave. These include the number field, select list, date picker, URL field, labels, and the checkbox.

Why are custom fields in Jira so useful?

The reason people love custom fields is because they’re a great way of adding functionality and usefulness to your Jira instance. They do this in three main ways:

Giving teams what they need on a Jira issue

Custom fields allow you to tailor your issues, and what they contain, to your team’s needs. They ensure you give your team members all the information they need to do the work.

Without custom fields, your Jira issues might have the basics required for the team to act, by virtue of what’s been entered in the system fields. But there would probably be a bunch of questions afterwards, such as:

• How big is this task?
• What’s the budget of this task?
• What exactly does this task relate to?
• How much impact will this task have?
• Does this task need approval?
• How much progress has there been on this task?

These are the sorts of questions you can answer by creating custom fields in Jira. As a result, your issues become excellent communicators because custom fields make sure no key information gets missed.

Making Jira issues easier to find

Custom fields hold searchable data. They make your tasks and stories easier to find because you can filter by the custom fields you’ve added to your instance.

For example, if you’re using the MoSCoW prioritization method (must have, should have, could have, won’t have), you might have created a MoSCoW rating custom field, probably using the single-select list custom field type that comes with standard Jira. You could then create a filter for “MoSCoW rating” in Jira’s basic search, and create “must”, “should” etc as values to be selected.

Improving Jira reporting

Custom fields provide data points that your Jira reports can be based on. Some standard Jira reports will allow you to select a custom field as your chart metric, depending on the field. But if you can’t select the custom field, what you can do instead is create a saved filter based on the custom field and report on that.

For example, you could run a search for all the issues that have the “should have” MoSCoW rating, then save the search as a filter. Then you can use that filter to create a chart and see, for example, which users the “should have” tickets are assigned to.

There are also some great custom reporting apps on the Atlassian Marketplace that support way more of the standard Jira custom fields than standard Jira does!

What is a Jira custom field made of?

Let’s open up a Jira custom field and see what’s inside, shall we? Because there are a few things to consider when creating one in your Jira instance.

Every Jira custom field has a number of attributes defining what data they can contain, and how this data will be presented and searched for.

Here’s a list of the attributes you’ll be manipulating when creating and working with Jira custom fields:

• Name
• Description – optional help text that will appear when the user hovers over the custom field
• Default value – you can set a value to appear by default in the field
• Context – this specifies the project(s) and issue types(s) that the custom field is allowed to be used on, and what options are available to be entered
• Screens – the specific screens of the project(s) and issue type(s) on which the custom field will appear, e.g. you might want a custom field to only appear on the “create” screen of the bug issue type
• Field configuration – optional behaviors for your custom fields
• Options – the values that users can choose to enter into certain custom fields such as the checkbox, select list, and radio buttons.

How to create custom fields in Jira

The creation process for Jira custom fields is pretty simple and involves heading over to “Issues” and clicking “Create custom field”. You can then choose from a variety of custom field types, such as a date picker, checkboxes, lists, radio buttons, and URLs.

Give your custom field a name and, if you wish, a short description, and click “Create”.

Finally, you have to associate your custom field to one or multiple screens. This is where you decide what projects and issue types your custom field will appear on. As a separate step, you can create different screen schemes to make sure your field only appears when you’re creating, editing, or viewing the issue.

And that’s it. Your custom field is now available for use.

Follow Atlassian’s step-by-step instructions on how to add custom fields in Jira along with some tips to consider when creating them.

How to configure Jira custom fields (if you need to)

The reason I say “if you need to” is because you don’t need to do anything further to start using your new custom field on issues. And it’s best to start tinkering with configurations on custom fields only if you absolutely have to.

For example, the default context when you make a field is global, which means your field is available everywhere. That doesn’t mean it will appear everywhere; you determine that by selecting screens and creating screen schemes. So you only need to change the context when you want to make different options available on different issue types/projects, or where you absolutely don’t want a custom field to ever be used on a certain project.

You may want to change the field configuration to give your custom field certain behaviors. These include hiding the field if your organization or project has no use for it, or requiring a value to be entered so that you can make sure certain information is captured every time. You can also create different field configurations for different issue types or projects. Again, the default configurations here are that custom fields are shown on all screens you’ve added them to, and fields are optional. And there are good reasons for keeping them that way (which we’ll come onto in the next section).

You may also want to add a default value, or limit the number of users that appear in a user picker field.

If you do need to do these things, then here are the steps for how to configure your Jira custom field.

How to avoid custom fields hell

Jira custom fields’ primary function is to enable team members to provide information about the work they’re doing. What you don’t want is for custom fields to get in the way of the work they’re doing.

The most common problem that leads companies to fall out of love with custom fields is overuse. Some companies have a tendency to create as many custom fields as possible for gathering every possible detail on all their issues. But a Jira issue is meant to facilitate a conversation between team members, not be the whole conversation by itself. Jira supports teamwork. It’s not supposed to replace it.

So here are some best practices for avoiding custom fields hell.

Challenge whether you need a custom field before you add it

If someone asks you for a new field, check if they want to use the information in the field for searching or reporting. If not or rarely, ask why the user can’t add the info to the issue description and search with a text search. You could also consider a free text field that could hold several values. And remember to utilize standard fields that may be ‘locked’, such as start date and end date, which just need enabling on screens.

If the person still wants a new field, try to use an existing custom field and define a new context for the person’s project or issue type. For example, if you have the single choice select list custom field, you can add a new context to make different options available to be selected.

Make custom field names generic

Keep your custom field names as non-specific as possible so that they can be reused. For example, don’t name your fields “Marketing Objective” or “Service Desk Rating”. Just name them “Objective” and “Rating”. It’s better to use context to tailor the options than to create a whole new custom field.

Don’t duplicate custom field names

All your custom fields should have unique names, so check to see whether a custom or standard field with the same name already exists before creating it. You don’t want two “status” fields in your instance. Duplicate names makes filtering and reporting difficult and confusing.

Consider which fields you need for reporting

One of the great things about Jira custom fields is the ability to report on them. But not all custom field types are made equal when it comes to this. Structured fields such as select lists and radio buttons are particularly effective because the user has a limited number of options to choose from. This means there’s a fixed set of options to filter and display in reports. Text fields, however, aren’t as useful because people don’t always enter data in the way a report’s query expects.

Use global contexts on custom fields and only change them if you have to

There is plenty of advice out there that says “don’t use global contexts”, partly because it can slow down your Jira. We don’t agree. There’s no actual proof that global contexts can impact performance unless you’re talking about hundreds of custom fields, particularly in Jira Cloud. (And we would argue that hundreds of fields is too many.)

And in any case, admin time is more important than computer time. You don’t want to have to go through the contexts of a couple of dozen custom fields every time you want to add a new project to your instance.

There aren’t many circumstances where you need to worry about the contexts of your Jira custom fields. Only when you want to offer the user different values to be selected without creating another custom field should you think about changing them.

Beware of making fields mandatory

If users are forced to fill in fields in order to create an issue, this can make the process slower and more difficult. Therefore, use required fields very sparingly and always offer a way for a user to say “I don’t know” so that they don’t put junk data into the required fields just so they can move ahead.

Beware of making default values

Default values are a double-edged sword. If, for example, the priority field has a default value such as “medium”, there can be a tendency to ignore the field and not actually think about prioritization. So if you want your users to actively engage with your custom fields, you might want to avoid default values.

Beware of making any configuration changes, actually

Changing contexts, adding default values, and making fields required are three of the Jira custom field configurations that we’ve kinda advised against doing unless you have to. You can also hide fields (but you could just change the screens the field gets displayed on, which would achieve the same result). And you can change how text fields are rendered/displayed too. Again, really not something to worry about.

Jira really could be accused of overengineering here, and if you want to remain a Jira fan, try to avoid getting caught up in its complexities.

What to do if the standard Jira custom fields aren’t enough

Standard Jira offers a wide range of functionality when it comes to custom fields. But the custom field types on offer may not be enough for what your company wants or needs to do.

Limitations and complexities of standard Jira custom fields

You’ll find that you may run into various limitations and/complexities when using the standard custom fields in Jira. Let’s take a look at a few examples.

Native issue links can overwhelm users by making them search through the whole instance and decide from countless options how the issues are related.

All standard Jira labels are grey, which kinda makes them invisible on an issue, even though you’re using them to quickly highlight an attribute.

The cascading select field only goes to two levels, but this amount of specificity might not be enough for your task.

These problems are where an Atlassian Marketplace app like Awesome Custom Fields can help. Awesome Custom Fields adds a range of new custom field types to your Jira. To combat the problems mentioned above, these include color labels, an enhanced cascading select field, and an issue picker.

The issue picker lets you add linked issues to your ticket but it allows an admin to limit how many issues show up when a user searches, e.g. only issues from one particular project. Also, the field doesn’t require the user to specify how the linked issue is related. This means it’s quicker and easier for the user to link tickets.

The cascading select field allows you to create as many levels of options as needed to cover your requirements. For example, your task might relate to a city, within a state, within a country, and you want to be able to select all three.

The color labels field lets you customize colors on each label. You could therefore have a green “Approved” label and a red “Rejected” label to instantly highlight what work can move forward and what work can’t. The field also stops users from creating their own labels just by typing them in, which leads to an instance cluttered with duplicate labels because of typos and spelling variations.