Automation For Jira - Some smart values are showing an 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

As explained in the documentation Smart values in Jira automation, smart values can be used in automation rules to display or manipulate Jira fields.

For example:

  • when using the smart value below in the log action:

    • {{issue.description}}

Automation rule to log issue description
  • we should be able to display the issue description in the rule audit logs:

    Automation audit log showing description

In some cases, smart values might return an empty value, as shown in the example below:

Automation rule audit log returning empty description

The purpose of this knowledge article is to list all the scenarios where a smart value can return an empty value, and how to identify each of them.

Solution

Root Cause 1 - The field is empty

If a field is empty, the smart value will return an empty value.

For example, let's assume that you are trying to log the description field in the rule audit logs. If this field is empty (as illustrated below), the audit logs will not show any data:

Jira issue highlighting Description field

Root Cause 2 - The field is configured to be hidden

As explained in the documentation Specifying field behaviour, it is possible to change the behaviour or Jira issue fields depending on the issue type by associating a Field Configuration to a specific issue type. If a field is configured to be hidden for a specific issue type, the automation rule will not be able to access it. As a result, even if the field is not empty, the smart value used to access this field will return an empty value.

To check if a field is configured a hidden for a specific issue type of a project, go to the page Project Settings > Field in the project administration, click on the Pencil icon next to the Field configuration and search for the field. If the link shown is visible next to this field, then it means that this field is set to hidden. In the example below, we can see that the Labels field is configured to be hidden:

Labels custom field highlighting SHOW option

Some fields can act in an unexpected manner when they are configured to be hidden. For example, when the linked issues field is set to be hidden, this field will still be displayed in the "View Issue" screen, even though it should be hidden, and even though automation rules can't access it. More about this behaviour in the KB article The "Delete Issue Links" action does not delete any link. For this reason, just because you are able to see a field in the "View Issue" screen does not necessarily mean that this field is not set to be hidden. Checking the Field Configuration page is the best way to tell if a field is hidden or not.

Root Cause 3 - The wrong syntax is used

When trying to manipulate or log Jira field values, it is very important to use the exact syntax. If the wrong syntax (for example upper case vs lower case) or the wrong custom field ID is used, the smart value will return an empty value.

Example 1: Jira system fields

The right syntax to access some of the Jira system fields is the following:

1 2 3 4 5 6 7 8 9 10 11 12 13 {{issue.key}} {{issue.description}}{ {issue.url}} {{issue.summary}} {{issue.assignee.displayName}} {{issue.reporter.displayName}} {{issue.status.name}} {{issue.issuetype.name}} {{issue.resolution.name}} {{issue.fixVersions.name}} {{issue.created}} {{issue.updated}} {{issue.project.name}}

Take note the cases (lower vs upper case) used for the fields issuetype or fixVersions:

  • If instead ofissuetype,issueType is used, the smart value will return an empty value

  • If instead offixVersions,fixversions is used, the smart value will return an empty value

Example 2: Custom fields

Custom Fields can be access either by using their field name, or by using the syntax customField_XXXXX, where XXXXX is the ID of the field (which you can get from the URL while configuring/editing any custom field). Let's assume that the ID of a custom field is 10500, but that there is no field with the ID 10700. In this case:

  • the following smart value will return the content of the field:

    • {{issue.customField_10500}}

  • the following smart value will return an empty value:

    • {{issue.customField_10700}}

Root Cause 4 - The lookup issue action is used and a non supported field is accessed via the smart value

As mentioned in the lookupIssues section of the documentation Jira smart values - issues, only a limited list of fields are available for this action. For example: custom fields, labels, and components are not supported by this action.

As a result, even if a Jira issue contains some values for a non supported such as the components field:

  • the syntax below will return an empty value:

    • {{lookupIssues.components}}

  • however, the syntax below will return a value

    • {{issues.components}}

There is an open feature request meant to support more fields with the lookupIssues action: JIRAAUTOSERVER-877 - Lookup issue action - Add support for more fields

Root Cause 5 - The "Issue Deleted" Trigger is used and limited fields are available

Not all the Jira fields are available via smart values when using the "Issue Deleted" trigger.

Some examples of fields which cannot be accessed via smart values are listed below (please note that the list might not be complete):

  • Any Version Type field (for example: "Fix Version/s")

  • The Components field

As a result, when using any of the smart values below along with the "Issue Deleted" trigger, an empty value will be returned:

  • {{issue.components.name}}

  • {{issue.fixVersions.name}}

This limitation is tracked in the open feature request JIRAAUTOSERVER-961 - Not all Jira fields are available via smart values when using the "Issue Deleted" trigger.

Root Cause 6 - The field is coming from a 3rd party add-on and is not supported by smart values

Smart values don't support all types of fields coming from third-party add-ons. For example, Script Fields from the ScriptRunner add-on cannot be accessed via Smart Values, and these fields will return an empty value.

There is an open feature request meant to add support for ScriptRunner script fields: JIRAAUTOSERVER-620 - Add support for ScriptRunner Script Fields to be detected via Smart Values

Root Cause 7 - The field was originally empty and updated inside the automation rule

If a field is empty when an automation rule is triggered and is set by the rule, the smart value accessing this value will be empty. This behaviour occurs because smart values reflect the content of the issue fields when the rule is triggered.

To ensure that the most up-to-date content of all the fields can be accessed via smart values (in the case where some fields might be modified by the rule), it is necessary to add Re-fetch issue data action (which is described in the documentation Jira automation actions), before using the smart value. This action will reload/refresh all the fields from the Jira issue to ensure that the rule contains the most up-to-date value of all the Jira fields.

Looking at the automation rule from the screenshot below:

  • The Description field is empty at the time the automation rule is triggered

  • The Description field is set by the automation rule

  • The 1st time we log the description field, we get an empty value even though the rule added a value do it

  • The 2nd time we log the description field, we get a non-empty value, which is because we used the Re-fetch issue data action

    Automation Rule to add description in the issue highlighting re-fetch data

Root Cause 8 - The rule is trying to access attributes from Assets (formerly called Insight) fields

The support for the Assets/Insight field is currently limited for Automation For the Jira Server/Data Center.

As a result, when trying to access field attributes using some syntax similar to the examples below, an empty value will be returned:

  • Example 1

    • issue.InsightField.<attribute>

  • Example 2

    • issue.InsightField.object.<attribute>

This limitation is tracked in the open feature request JIRAAUTOSERVER-313 - Support access of all Insight attributes through smart values GATHERING INTEREST

Root Cause 9 - The rule is trying to access a variable that was created inside a branch

Variables created inside the branch of a rule are not accessible outside the branch. As a result, when trying to access this variable outside the branch via a smart value, the smart value will return an empty value.

This limitation is tracked in the open feature request JIRAAUTOSERVER-985 - Automation: Ability to use variable outside of a block - variable is not updated on the main branch if created inside an if/else or branch block GATHERING INTEREST

Root Cause 10 - The rule is trying to access the smart value "webhookData.issues"

As mentioned in the KB article Working with incoming webhook data in Automation for Jira, it is possible to use the webhookData smart value to retrieve information coming from the incoming webhook payload.

It is important to know that if the webhook payload includes issues as a parameter, the content of this parameter will be removed from the webhookData smart value and will be moved into the issues smart value instead.

As a result, the expression below will always return an empty output:

  • {{webhookData.issues}}

Example

Let's take the example of the incoming webhook payload below:

1 2 3 4 5 6 { "issues": [ "GRD-4000" ], "data": {"releaseVersion":"5.3.2"} }

In such cases:

  • the content of the issue parameters will be moved to the issues smart value, and will be accessed using the syntax below:

    • {{issues}}

    • {{issues.key}}

    • {{issues.summary}}

    • etc...

  • the rest of the data will be contained in the webhookData smart value, and will be accessed using the syntax below:

    • {{webhookData}}

  • using the expression above will provide the output below:

    • {"releaseVersion":"5.3.2"}

  • using the syntax below will not return anything:

    • {{webhookData.issues}}

Updated on June 7, 2024

Still need help?

The Atlassian Community is here for you.