Enforcing Required Fields in Jira Cloud

Requiring users to fill-in important fields on a record is a basic workflow control in any system.  In this tutorial, we’ll review two strategies for implementing required fields in Jira Cloud.  We’ll also review how one strategy typically results in higher quality data than the other.

Two Strategies for Enforcing Required Fields

Jira Cloud supports two strategies for configuring and enforcing required fields in a workflow:

1. Always Required:  Through field configurations, you can specify that a field is always required.  This means that the field must always have a value during creation, editing, transitions…everywhere.
2. Transition-based:  Using transition validators (or transition conditions), you can enforce that a field is required for specific transitions in the workflow.  This means that the field can remain blank in some workflow statuses, but it must have a value before progressing to other statuses downstream in the workflow.

Advantages/Disadvantages of Each Strategy

Each strategy has its own advantages and disadvantages, and choosing as strategy will depend on the nature of the field you are requiring.

Always Required:  The advantage to making a field always required is that it makes it impossible for users to forget to complete it.  For example, the Summary field in Jira is always required (by default).  This is helpful because the Summary field acts as the name field for issues in Jira, and every record must have a name.

The disadvantage to always requiring a field is that users are more likely to fill in the fields with inaccurate (bad) data.  They want the system to let them save their changes, and so they’ll either enter TBD, N/A, or make a guess for any required fields that are still blank.  This is a common occurrence for fields like Priority, Severity, and Components, where the person submitting the issue might know the right data for those fields.

Transition-based:  The advantage to requiring fields on specific transitions is that it allows you to defer making the field required until later in the workflow.  This encourages users to leave those fields blank until they can consult with the correct team members, which ultimately results in higher quality data in your system.

The disadvantage to this strategy is that users are more likely to submit incomplete records, which will require you to ask for that data later on.  “Steps to Reproduce” on a defect may be a good example.  Most people submitting a defect are likely to know the steps to reproduce, but they are unlikely to fill-in that field if it’s not required.  This will slow the process if you have to circle-back with the reporter on every defect to ask for that additional info.

Choosing a Strategy

Which strategy is best?  The decision should be based on whether the original submitter is likely to know the information.  For basic data like Summary, Description, and Steps to Reproduce, the original submitter is likely to know the information.  In fact, they may be the only person that knowns this information.  So making these fields always required is probably a good choice.  This will prevent you from needing to circle-back with the submitter later on.

For all other fields, transition-based enforcement is probably best.  This provides the team with the most opportunity to collaborate and provide good data.  When in doubt, this should be your default strategy.

Configuring “Always Required” Fields

In Company-manage Projects

1. As a site administrator, go to Settings –> Issues –> Field configurations.
2. Select your project’s field configuration from the list.  (You may only have one:  Default Field Configuration.)
3. Use the search text box to locate your field by its label.
4. When you find your field, press Required under the list of Actions.  The screen should refresh, and you should see an indicator that the field is now “Required”.
5. Repeat steps 3 and 4 for all other fields you want to make always required.

Tip:  If you want a field to be always required for some projects but not others, then create a new field configuration instead of updating the default field configuration.

In Team-managed Projects

1. As a project administrator, go to Project Settings –> Issue types.
2. Select the target issue type.
3. Locate your target field in the list of fields and expand the field’s configuration pane.
4. Select the Required checkbox.
5. Repeat steps 3 and 4 for all other fields you want to make always required.
6. Press Save changes.

Configurating Workflow Validators

In Company-manage Projects

1. As a site administrator, go to Settings –> Issues –> Workflows.
2. Find your project’s workflow in the list, and select Edit under Actions.
3. Find the transition on which you want to add field validation.
4. Select to open the transition details.
5. Select Validators.
6. Select Add validator.
7. Select Field Required Validator and press Add.
8. Select your target field(s) from the drop-down list and enter a useful error message for users.
9. Press Add.
10. Repeat steps 3 through 9 for all transitions on which you want to add validation.
11. Select Publish Draft.  (Save a back-up if desired.)

In Team-managed Projects

1. As a project administrator, go to Project Settings –> Issue types.
2. Select the target issue type.
3. Select Edit workflow.
4. Find the transition on which you want to add field validation.
5. Select to add a new rule.
6. Select “Restrict to when a field is a specific value“, and press Select.
7. Select your target field from the drop-down list.
8. Configure the following options:
   • Review its value as:  Text
   • Check if it:  Doesn’t equal
   • This value:  [leave this option blank]
9. Press Add.
10. Repeat steps 4 through 9 for all transitions on which you want to add field enforcement.
11. Select Update workflow, and confirm the issue types on which the updated workflow should be applied.

More Information

Find more strategies like this in my Quick Start Guide for Jira Cloud:  https://www.agile-innovations.tech/part-11