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

jira custom fields ultimate guide - header image

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.

jira custom fields ultimate guide - fields

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.

jira custom fields ultimate guide - searching for MoSCoW rating

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.

jira custom fields ultimate guide - dragging in new custom field called Labels

jira custom fields ultimate guide - giving new Labels field a name

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.

jira custom fields ultimate guide - Awesome Custom Fields issue picker configuration

jira custom fields ultimate guide - Awesome Custom Fields cascading select field

jira custom fields ultimate guide - Awesome Custom Fields color fields setup

Enhanced Jira project management

Of course, a custom fields app can do more than just extend the capabilities of the standard fields and let you display more information on an issue, or display it in a different/better way.

In addition to making Jira issues better at communicating key information and more visually appealing, the additional custom field types that come with Awesome Custom Fields can also enhance your project management. This is by allowing you to do things that you can’t in standard Jira, such as estimating and prioritizing differently.

For example, there is a MoSCoW prioritization field that features colored cards for each priority, the size of which you can customize. There is also a weighted shortest job first (WSJF) field, a traffic lights field, and a priority matrix. And Awesome Custom Fields gives you the option to estimate based on T-shirt sizes and price tags.

The custom field types offered with Awesome Custom Fields can help with tracking and understanding progress on tasks with more speed, too. For example, Jira offers a due date field, but Awesome Custom Fields has a due date countdown so you can see at a glance how much time is left. There is also a visual progress bar whose value can be manually edited or based on the number of closed child issues.

jira custom fields ultimate guide - multiple Awesome Custom Fields in action

Jira Service Management custom fields

One of the most important benefits of Awesome Custom Fields is that it comes with a Jira Service Management (JSM) extension. There are other apps that offer custom fields for Jira Service Management, but Awesome Custom Fields is the only one that lets customers see and use those fields in the JSM portal.

So, using Awesome Custom Fields means a customer can add extra detail to their requests, making them easier for agents to work on. At the same time, agents can give customers additional information about their tickets, such as the estimated size of the job in T-shirt sizes.

jira custom fields ultimate guide - Awesome Custom traffic light field

To summarize (TL;DR)

  • Custom fields in Jira are super-useful because they allow you to tailor your Jira issues to your team’s needs and add details like budget, size, impact, and how much time is left. They also improve filtering and reporting in Jira by giving you new data points.
  • Jira custom fields are really easy to create, but configuring them is a different story. However, you don’t actually need to configure them to start using them straight away, and a lot of the configuration options are not worth worrying about.
  • Jira admins should avoid allowing too many custom fields to be created and should always question whether a new one is needed. An overabundance of fields is a surefire path to custom fields hell.
  • Keep custom field names generic so they can be reused, and don’t duplicate them.
  • A lot of the best practices for Jira custom fields amount to: don’t mess about with custom field configurations 🤣. For example, keep contexts global where you can and avoid default values and mandatory fields.
  • Custom fields in Jira have their limitations and complexities, and you may find you need an app from the Atlassian Marketplace like Awesome Custom Fields to counter those problems.
  • An app like Awesome Custom Fields also offers enhanced project management capabilities. For example, estimating in T-shirt sizes instead of story points, using WSJF and MoSCoW to prioritize, and checking progress on tasks with a progress bar and a completed story points field.
  • Awesome Custom Fields is the only Atlassian app that lets customers see and use 3rd party custom fields in the JSM portal.

If you’re looking to extend the visual and project management functionalities of standard Jira’s custom field options, book a personal demo of Awesome Custom Fields, or you can download the app for free on the Atlassian Marketplace.


Further Reading

Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud