Avoiding problems with JIRA fields – Part 1

Problems with JIRA fields

Whilst JIRA is an intuitive, user-friendly platform, development teams and administrators can sometimes get into difficulties simply by overlooking the fundamentals. In this, the first in a series of posts focussing on the basics of JIRA, we look at System and Custom fields and provide key recommendations to help you avoid some of the more common problems with JIRA fields.

Understanding JIRA fields

Most will be familiar with the concept of form fields, but those new to JIRA may bring preconceptions that can cause problems further down the line. Often JIRA novices try to apply previous ways of working to the Atlassian project tracking product. This results in unnecessarily complex system configurations or a reduction in the usefulness of the underlying data.

It’s crucial – if you want to avoid problems with JIRA fields further down the line – to understand their role and function and appreciate 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 logically grouped together on screen.

Some 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

  • 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. It’s completely possible to set up projects and issue types so that their fields and workflows are very different.
  • 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.
  • The Priority field is a globally set list of values, so always consult users when creating or amending it.
  • 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).
  • Monitor the use of Labels – you may identify candidates for new Custom fields.
  • 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.
  • The ability to choose a Reporter, as opposed to a Creator, can be useful when raising issues on behalf of other people. However, when done 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 the admin’s problems with JIRA fields.

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

A common area of confusion with Custom fields concerns the difference 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 how to display, store and edit the data.

Best practice for JIRA Custom fields

  • Custom fields should only be used where a System field is not appropriate.
  • Adding Custom fields leads to increased complexity so their use must therefore be fully justified.
  • Wherever possible re-use Custom fields – this helps reduce complexity and simplifies reporting.
  • JIRA will sometimes allow you to create multiple fields with the same name, causing big problems. Ideally these fields should be merged but if that is not appropriate rename them to guarantee their uniqueness.

In our next post we will focus on some of the specific System fields that can cause issues. Meanwhile, if you are encountering any issues with your own JIRA deployment, or would like to find out more about how Adaptavist can help you harness the power of JIRA for your projects, contact us now.