Automation For Jira - Some smart values are showing an empty value

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}}

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

  

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

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:

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:

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:

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

  

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:

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}}

Root Cause 11 - The rule is trying to access the smart value "webhookResponse.body"

As explained in the documentation Jira Smart Values - Issues, when using the Send Web Request action, it is possible to access the data from the Webhook response by using the smart value below: {{webhookResponse.body}}

This Smart Value will not return anything, unless the option Wait for response → Delay execution of subsequent rule actions until we've received a response for this webhook is ticked:

If this option is not ticked, the automation rule will not wait until it gets a response from the Webhook, and the Smart Value webhookResponse.body will be empty, since the rule did not get a chance to populate it.

Root Cause 12 - A variable is used in a string manipulation function and gets treated as a blank value

Automation For Jira 9.0 (which ships with Jira 9.11.0) introduced a new action called Create Variable. This action allows you to store the content of a smart value inside a variable, which will be available within the entire scope of the rule, including inside branches.

As explained in the bug String manipulation functions do not work properly with variables, when variable is used inside in a String manipulation function (such as concat(), replace(), replaceAll(), etc...), that variable will be treated as blank (even if this variable was created to contain the value of a Text Field).

For example, let's assume that a rule is configured:

• to create a variable with name variableContainingSummary is configured to contain an issue summary with the Smart Value below:

  • {{issue.summary}}

• to log the the syntax below in an audit log action:

  • {{issue.key.concat(variableContainingSummary)}}

The rule would look like this:

In this case, the syntax {{issue.key.concat(variableContainingSummary)}} will return a blank output.

To be able to use the variable inside a string manipulation function, it is necessary to add .trim() at the end of the variable name, to force it to be treated as a String instead of being treated as blank. Using the example above, it can be modified as shown below to properly use the variable in the concat function:

{{issue.key.concat(variableContainingSummary.trim())}}

Root Cause 13 - The issue.id smart value is used in a string manipulation function

Using the issue.id smart value (contrary any other issue smart values such as issue.key, issue.summary...) in a string manipulation function will lead to a blank output. If we take the rule illustrated in the screenshot below, the log action will return a blank output:

At the time this KB article was created, it is not clear yet if it is due to a bug or expected (due to the type of variable issue.id is of).

As a workaround, we recommend the following approach:

• Use the Create Variable action and store the issue.id smart value inside the variable (let's call the variable variableContainingIssueId):

  • {{issue.id}}

• Access the issue ID in the string manipulation function by using the variable followed by .trim(), as illustrated below:

  • Issue Summary-Key: {{issue.summary.concat("-").concat(variableContainingIssueId.trim())}}

The suggested rule would look like this:

Root Cause 14 - The issue.id smart value is used in a string manipulation function

Using the {{issue.id}} smart value (contrary to any other issue smart values such as {{issue.summary}}, {{issue.description}} ...) in a string manipulation function will lead to a blank output.

If the text below is added to a log action, this action will return a blank output:

Instead, we recommend configuring a rule that will have the 2 actions below:

• Use the Create Variable action and store the issue.id smart value inside the variable (let's call the variable variableContainingIssueId):

• Access the issue ID in the string manipulation function by using the variable followed by .trim(), as illustrated below:

For an example of rule where using the issue ID in a string manipulation function can be useful, please refer to the article How to write a rule that will send an email including the customer facing URL of the attachments.

Root Cause 15 - The custom field accessed by the smart value is translated into a language other than English

If a custom field is translated to other languages, all the smart values that refer to this field will return an empty value if the rule actor's profile is configured to use another language than English.

For example, let's assume that:

• the Story Points custom field is configured to have a German translation

• the rule actor has their profile setting configured with the German language

• the rule is configured to access the Story Points custom field via the smart values below

In this case, all these smart values will return an empty value, and to prevent this behavior from happening, we recommend changing the rule actor to a user whose profile is configured with the English knowledge.

This behavior was reported as a bug in the ticket JIRAAUTOSERVER-1025

Root Cause 16 - The smart value is used in an "Edit Issue" action with the "Choose fields to set..." option and with a list type field

If a list type field such as the Components field is set through the Choose fields to set... option, the syntax below will copy an empty value if the Components from the Trigger Issue has multiple values:

The reason behind this is the fact that the smart value is being treated in the "Choose fields to set..." option as a string rather than a list of component names. As a result, if the component contains multiple values, the list of component names will be converted into a string and the rule will try to copy a string value into the Components field, which will not work. As a result, the Components field will be set to an empty value.

This behavior is tracked in the bug JIRAAUTOSERVER-1072.

To ensure that the Components field (or any other list type field) is copied properly, use the option Issue to copy value from along with Trigger Issue instead of using a smart value.