Best practice for using Jira fields (Part 1/2)

While Jira is an intuitive, user-friendly platform, development teams and administrators can sometimes get into difficulties when using it by overlooking a few fundamentals.

In this first post in a two-part series, we focus on the basics of Jira, we look at system and custom fields and provide key recommendations to help you avoid some of the most common problems experienced when using Jira fields.

Understanding Jira fields

If you are reading this post, most of you will already be familiar with the concept of form fields, but if you are new to Jira you may have preconceptions that could cause challenges for you further down the line.

If you want to avoid problems when using Jira fields, it's crucial to first understand the role and function of Jira fields and how this might differ from other platforms.

System fields - underpinning Jira

With significant levels of functionality built around them, system fields are integral to the operation of Jira. These built-in fields for example project, issue type, created date, priority and due date are available to all Jira instances and are grouped logically together on one screen.

Some fields are structural, some are automatically maintained and many play a role beyond their basic data-holding function. In addition, many Jira add-ons, such as 'Agile', 'Capture' and 'Service Desk', come with their own additional system fields.

Best practice for Jira system fields

1. When creating a new Jira instance consider the nature of your project and, where possible, simplify the field list accordingly. For example, not every project will need an environment field. Its completely possible to set up projects and issue types so that their fields and workflows are very different.
2. The summary field is mandatory and must always appear on the issue create screen. Even if you pre-populate it or code some changes later, it must contain data.
3. If you are on Jira Cloud or an older version of Jira, remember that the priority field is a global set list of values, so always consult users when creating or amending it. If you are working on a newer version of Jira, you can resolve this issue with the 'priority schemes' feature.
4. The label field is also global, but within its own field context. To create labels that belong to a single project or group of projects, use a separate label field (using the field context to control this).
5. By monitoring the use of labels you may identify candidates for new custom fields.
6. Editing the due date field is granted via the schedule issues permissions. This also controls the authority to rank issues on boards, so consider its use carefully if using the Agile add-on.
7. The ability to choose a reporter, as opposed to a creator, can be useful when raising issues on behalf of others. However, when performed as part of the initial issue creation, the record of the person actually inputting the issue is lost. If you allow editing of the reporter field in earlier versions of Jira, consider adding a field for creator and use a post-function on the create issue transition to set it to the current user.

Flexible configuration

In addition to the standard system fields, Jira provides the ability to add custom fields. There are over 20 configurable field types and these can be a major cause of problems for Jira admins.

Custom fields available out-of-the-box include checkboxes, radio buttons, date-pickers and free text field. Additional fields can be purchased online or developed in-house.

A common area of confusion with custom fields is distinguishing between fields and field types. Whilst a field is for storing data, a field type describes the rules governing it, such as the format and the 'how to' display, store and edit the data.

Best practice for Jira custom fields

1. Custom fields should only be used where a system field is not appropriate.
2. Adding custom fields leads to increased complexity so their use must be always be justified.
3. Wherever possible re-use custom fields as it helps reduce complexity and simplifies reporting.
4. Jira will sometimes allow you to create multiple fields with the same name, this can cause huge problems. Ideally these fields should be merged but if that is not appropriate rename the fields to guarantee uniqueness.

Join us again for our second post in this series, where we focus on some of the specific system fields that can cause issues.

In the meantime, if you encounter any issues with your Jira deployment, or would like to find out more about how our team at Adaptavist can help you harness the power of Jira for your projects, contact us now. 

Read the next blog