You can use smart values in automation rules to display or manipulate Jira fields. For example, when using the smart value {{issue.description}} in a log action:

• You should be able to display the issue description in the rule audit logs:
  
• However, there might be some cases where this smart value (or any other smart value) might return an empty value, as shown in the example below:
  

This knowledge article lists some scenarios where a smart value can return an empty value and explains how to identify each one.

This list isn't exhaustive and more scenarios might be added in the future.

On this page:

• Root cause 1: Field is empty
• Root cause 2: Field is configured to be hidden
• Root cause 3: Multiple custom fields have duplicate names
• Root cause 4: Lookup issue action is used and a non-supported field is accessed via the lookupIssues smart value
• Root cause 5: "Issue Deleted" trigger is used and limited fields are available
• Root cause 6: Field is coming from a third-party app and isn't supported by smart values
• Root cause 7: Field was originally empty and updated inside the automation rule
• Root cause 8: Rule is trying to access attributes from Assets fields
• Root cause 9: Rule is trying to access a variable that was created inside a branch
• Root cause 10: Rule is trying to access the smart value "webhookData.issues"
• Root cause 11: Rule is trying to access the smart value "webhookResponse.body" or "webhookResponse.body.<key_name>"
• Root cause 12: A variable is used in a string manipulation function and gets treated as a blank value
• Root cause 13: The issue.id smart value is used in a string manipulation function
• Root cause 14: Custom field accessed by the smart value is translated into a language other than English
• Root cause 15: Smart value is used in an "Edit'ssue" action with the "Choose fields to set..." option and with a list type field

Environment requirements

Starting from Jira Data Center 10.0, we integrated Jira automation (formerly Automation for Jira) as part of Jira Data Center (both Software and Service Management), offering you the convenience of upgrading either through Jira or the Universal Plugin Manager (UPM). To streamline and enhance your experience with Jira automation, we've decided to solely offer it as a bundled version starting from Jira 10.0.

This guide assumes that you're using:

• Jira Data Center 8.0.0 or later
• Jira automation Data Center 7.4.0 or later

Root cause 1: Field is empty

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

For example, let's assume you're trying to log the description field in the rule audit logs. The audit logs won't show any data if this field is empty.

Root cause 2: Field is configured to be hidden

It's possible to change the behavior 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 won't be able to access this field. As a result, even if the field isn't empty, the smart value used to access this field will return an empty value.

To check if a field is configured and hidden for a specific issue type of a project:

1. In the project administration window, go to Project Settings > Field.
2. Next to the Field configuration, search for the field.

If the link Show 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're configured to be hidden. For example, when the linked issues field is set to be hidden, it'll still be displayed in the View Issue screen, even though it should be hidden and automation rules can't access it. For this reason, just because you can see a field in the View Issue screen, this doesn't necessarily mean that this field isn't set to be hidden. Checking the Field Configuration page is the best way to tell whether a field is hidden. For more information, go to The "Delete Issue Links" action doesn't delete any link.

When manipulating or logging Jira field values, use the exact syntax. If you use the wrong syntax (for example, upper case vs. lower case) or the wrong custom field ID, 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:

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

The cases (lower vs upper case) are used for the fields issuetype or fixVersions:

• If instead of issuetype, issueType is used, the smart value will return an empty value
• If instead of fixVersions, fixversions is used, the smart value will return an empty value

Example 2: Custom fields

Custom Fields can be accessed 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 any custom field). Let's assume the ID of a custom field is 10500, but 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 3: Multiple custom fields have duplicate names

If multiple fields have the same name, the smart value {{issue.<field_name>}} will return an empty value, as it can't identify which field value should be returned.

Let's take the example of the Story Points field:

• Jira allows admins to create fields with duplicate names. One field is a custom text field, and the other field is the original Story Points field, which is of type number:
  

• In such condition, if an automation rule is configured to log the content of the Story Points field with the syntax below, the rule will log an empty value, as it's unable to identify which one of the two Story Points fields is the "correct" one:

  {{issue.Story Points}}

  

Suggestions: For such situations, we recommend to:

• Rename the duplicate field (the custom Story Points field in the example above) to a different unique name.
• Another option is to access the correct custom field using its custom field ID in the syntax below (replace XXXXX with the field ID).  However, this workaround won't work with the lookupIssues smart value, as it doesn't support the customField_XXXXX syntax.
  

Root cause 4: Lookup issue action is used and a non-supported field is accessed via the lookupIssues smart value

lookupIssues supports only a limited list of fields. For example, this action doesn't support custom fields, labels, and components.

As a result, even if a Jira issue contains some values for a non-supported field, 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 - Getting issue details... STATUS

Root cause 5: "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 that can't be accessed via smart values are listed below (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 value 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 - Getting issue details... STATUS

Root cause 6: Field is coming from a third-party app and isn't supported by smart values

Smart values don't support all types of fields from third-party apps. For example, Script Fields from the ScriptRunner app can't be accessed via smart values and will return an empty value.

There is an open feature request meant to add support for ScriptRunner script fields: JIRAAUTOSERVER-620 - Getting issue details... STATUS

Root cause 7: 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 behavior occurs because smart values reflect the content of the issue fields when the rule is triggered.

To ensure that all fields' most up-to-date content can be accessed via smart values (where the rule might modify some fields), add the Re-fetch issue data action before using the smart value. This action will reload all the fields from the Jira issue to ensure that the rule contains the most up-to-date value of all the Jira fields.

For example, in 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 first time we log the Description field, we get an empty value even though the rule added a value.
• The second 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: Rule is trying to access attributes from Assets fields

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 - Getting issue details... STATUS

Root cause 9: Rule is trying to access a variable that was created inside a branch

Variables created inside the branch of a rule aren't 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 - Getting issue details... STATUS

Root cause 10: Rule is trying to access the smart value "webhookData.issues"

When working with incoming webhook data in Automation for Jira, it's possible to use the webhookData smart value to retrieve information from the incoming webhook payload.

If the webhook payload includes issues as a parameter, the content of this parameter will be removed from the {{webhookData}} smart vlue and will be moved into the {{issues}} smart value instead.

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

{{webhookData.issues}}

{
  "issues": [
    "GRD-4000"
  ],
  "data": {"releaseVersion":"5.3.2"}
}

Root cause 11: Rule is trying to access the smart value "webhookResponse.body" or "webhookResponse.body.<key_name>"

When using the Send Web Request action, it's possible to access the data from the webhook response by using the smart value below:

{{webhookResponse.body}}

There can be various reasons why this smart value might be empty when used in an automation rules. We've listed them in the following article: Automation For Jira: Getting an empty value when using the webhookResponse smart value.

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

In Jira automation 9.0, we implemented 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. 

When a variable is used inside in a string manipulation function (such as concat(), replace(), or replaceAll()), that variable will be treated as blank (even if this variable was created to contain the value of a Text Field). We've documented this in the following article: String manipulation functions do not work properly with variables.

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 variable in a log action using the syntax below. This will return a blank output.

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

  

To use the variable inside a string manipulation function, add .trim() at the end of the variable name. This will treat it as a String instead of being treated as blank. You can modify it 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 to any other issue smart values such as  {{issue.summary}}, or {{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:

Issue Summary-ID: {{issue.summary.concat("-").concat(issue.id)}}

Instead, we recommend configuring a rule that will have two actions:

• 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():

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

For a use case of rule using the issue ID in a string manipulation function, see How to write a rule that will send an email including the customer facing URL of the attachments.

Root cause 14: 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.

  {{issue.Story Points}}
  {{triggerIssue.Story Points}}
  {{lookupIssues.Story Points}}

In this case, all these smart values will return an empty value. 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 following ticket:  JIRAAUTOSERVER-1025 - Getting issue details... STATUS .

Root cause 15: Smart value is used in an "Edit'ssue" 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:

{{#triggerIssue.components}}{{name}}{{/}}

This happens because 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 won't work. As a result, the Components field will be set to an empty value. This behavior is tracked in the bug JIRAAUTOSERVER-1072 - Getting issue details... STATUS .

To ensure 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.