Automation for Jira - How to create a rule that is only executed if a field was set from an empty value to a non empty value

Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.

Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Summary

This article explains how to create a rule that executes an action when a specific field changes from an empty value to a non-empty value.

Solution

To check if a specific field was changed from an empty value to a non-empty value, you will need to use the Value changes for trigger along with the Advanced compare condition block in your automation rule.

The automation rule will look like this:

  • Add the WHEN: Value changes for trigger, and choose the field of your choice

  • Add the block Advanced compare condition after the trigger and fill in the fields as shown below:

    • First value: use the following smart value:{{fieldChange.fromString}}

    • Condition: equals

    • Second value: leave it empty

The automation rule will look like this in the screenshot below, assuming that the field in question is the Sprint field and that you are trying to edit the issue:

Automation rule that is only executed if a field was set from an empty value to a non empty value

Known issues related to this solution

This solution will work for any type of Jira custom fields, except for the types listed below:

  • Fix Version/s

  • Affects Version/s

  • Component/s

This limitation comes from the fact that:

  • Automation For Jira relies on the Jira issue history to populate the #fieldChange smart value.

  • The values shown in the issue history are inconsistent for these 3 types of fields

  • This inconsistent behavior is described in the bug ticket JRASERVER-69307-(Values are not captured in the History tab properly when the component and version fields have multiple values)

Due to the bug which impacts the issue history, in some cases the Advanced Compare Condition will incorrectly "think" that the previous value of these fields was empty even though it was not. For this reason, we advise to not use this solution for the types of fields listed above.

Updated on June 7, 2024

Still need help?

The Atlassian Community is here for you.