JIRA Custom Fields

Daniel Vargas Llopis | Tue, July 04, 2017 | Atlassian Products | 1 comment

What are Custom Fields?

JIRA comes with many built-in fields that store different information in an issue, such as Status, Priority, Description or Estimate time. More examples can be found here.

The majority of these fields are relevant to everyone, but most of the time users will need a way to enter more specific information that might be unique to their organisation.

Why are Custom Fields useful?

Custom Fields enable users to capture useful information in lots of different formats such as numeric, check boxes, select lists, and cascading lists.

These fields can then be displayed in issue screens, search results, and reporting.

With each JIRA installation, you gain access to the following field types. Many more are available in the Marketplace (and many are available for free)!

• Checkboxes: Choose multiple values using checkboxes
  
• Date Picker: A Custom Field that stores dates and uses a date picker to view them
  
• Date Time Picker: A Custom Field that stores dates with a time component
  
• Labels: Add arbitrary labels to issues
  
• Number Field: A Custom Field that stores and validates numeric (floating point) input
  
• Radio Buttons: A list of radio buttons
  
• Select List (cascading): Choose multiple values using two select lists
  
• Select List (multiple choices): Choose multiple values in a select list
  
• Select List (single choice): A single select list with a configurable list of options
  
• Text Fied (multi-line): A multi-line text area Custom Field to allow input of longer text strings
  
• Text Field (single-line): A basic single line text box Custom Field to allow simple text input
  
• URL Field: Allow the user to input a single URL
  
• User Picker (single user): Choose a user from the user base via a popup picker window
  

A really useful Custom Field feature is that of context: enabling different options for different projects using the same Custom Field.

E.g. you can have a Custom Field ‘Hardware’ to specify hardware that is faulty, and have different options depending if the request is a Network issue (router, network card, Wi-Fi card…) or if it’s a request to purchase new hardware (laptop, monitor, keyboard…).

Make sure your custom fields are relevant!

Before creating a Custom Field, make sure that it’s really needed and will add value to the business. Ask yourself these questions:

• Is the Custom Field going to be useful? If a Custom Field is not really useful, the end user may just end up entering meaningless data.
  
• Do we need to capture this information from the user? Users might not be able to provide the required information. Consider who will be entering the data and what they might know.
  
• Is the data in the Custom Field going to be used on reports? If data is entered but never used, it might not be that useful and could be a waste of time and resources.
  
• How is the data in the Custom Field going to be used? Is it going to be used for reports, solve users problems (e.g. a technical problem with a machine), etc…
  

Atlassian has extensive documentation on how to add a Custom Field, and how to configure a Custom Field.

Custom Field Use Cases

So, what might you need custom fields for? We’ve included some random and common use cases below:

• Contact Information: when a customer raises a request, their account can be associated with their email address, but more contact information might be needed, such as a contact number or when is the customer available.
  
• Location: very useful for a customer or an employee to specify their location, as the same service desk can be used for different offices, but depending on the location the issue will be assigned to a specific IT team.
  
• Serial Number / Reference Number: crucial information when raising a request related to any software, as including the serial number or reference number can help with the verification process and to check support entitlement.
  
• Hours: in a Service Desk, this could be used to indicate the number of purchased support hours for example.
  
• Client/Supplier: instead of having separate projects for each client or supplier, a Custom Field could capture this information.
  
• Reason for delay: this information could get lost in comments, and a custom field could capture it for reporting purposes.
  
• Applications / Products: similar to platform, but the list would include a closed set of applications or products, either for support, for a sales team or a development team.
  
• URL: a URL, e.g. URL of a new feature, URL of where the bug is occurring, a test URL.
  
• Platform: this could be used in addition to the built-in Environment field for a Service Desk when a user is requesting support (e.g. Android, iOS).
  
• Invoice Ref: an invoice reference if you’re using JIRA to capture and track invoices.
  
• PO Ref: a Purchase Order reference, again if you’re using JIRA to capture and track invoices.
  
• Additional notes: any additional notes that might be useful to add to a ticket could be captured in a Custom Field, as the information could get lost in the comments.

Best Practices

Don’t duplicate fields

Use as few Custom Fields as possible - a high number of Custom Fields can affect performance.

Don’t duplicate Custom Field names

This creates confusion and makes it difficult to search and report.

Use closed-set fields for reporting

Free text fields are not useful for reporting - use them only when it’s absolutely necessary.

Use generic names

By using a generic name for a Custom Field, it will be possible to use the same Custom Field in different projects/contexts (‘Hours’ vs ‘Hours purchased’, ‘Objective’ vs ‘Strategic objective’).

Don’t make names descriptive

Don’t use long names for Custom Fields, as it will be difficult to use them as JQL statements, search results, and in reports.

Add a generic description when creating a Custom Field

• Use the description field so users know what kind of information is required (e.g. for a Custom Field ‘Hours’, add a description to capture the required format - 1.5h or 1h 30m).
  
• Ensure the description is generic so the Custom Field can be used for different projects.
  

Use Custom Fields instead of labels

Labels are free text so any user can create a new label at any time, making them difficult to use for reporting.

Remove unused fields on JIRA screens

Remove any unused fields to make JIRA as user friendly as possible.

Order fields on JIRA screens

As new Custom Fields are added to the bottom of screens by default, ensure that the order of the fields make sense to the end user.

If you must make fields mandatory, proceed with caution

When a user has no choice but to enter the information in the field, you may end up with false information. Before making a field mandatory, consider whether most users will have the right information to hand.