Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Jira Automation smart value comparison fails even when values appear identical

Ramya R
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
March 4, 2026

The API response contains two locations where the same value exists:

  1. In the customFields definition object.

  2. In the virtualVersions.customFields map, where the key is the custom field ID.

Example structure from the response:

"customFields": [
  {
    "id": "69a18668c0386b0f42a6cbb5",
    "options": [
      {
        "id": "69a1866ec0386b0f42a6cbb6",
        "label": "yes"
      }
    ]
  }
]

And in the virtual version object:

"virtualVersions": [
  {
    "id": "694561558c4ed6a5f5230139",
    "customFields": {
      "69a18668c0386b0f42a6cbb5": "69a1866ec0386b0f42a6cbb6"
    }
  }
]

So the option ID (69a1866ec0386b0f42a6cbb6) appears in both places.

Smart values used

To extract the option ID for label yes:

{{#webResponse.body.customFields}}
  {{#if(equals(id,"69a18668c0386b0f42a6cbb5"))}}
    {{#options}}
      {{#if(equals(label,"yes"))}}
        {{id}}
      {{/}}
    {{/options}}
  {{/}}
{{/webResponse.body.customFields}}

To extract the value from the virtual version:

{{#webResponse.body.virtualVersions}}
  {{#if(equals(id,"694561558c4ed6a5f5230139"))}}
    {{customFields.69a18668c0386b0f42a6cbb5}}
  {{/}}
{{/webResponse.body.virtualVersions}}

The problem

Both values appear identical in logs:

69a1866ec0386b0f42a6cbb6

However, when I use an Advanced compare condition:

{{value1}} equals {{value2}}

Screenshot 2026-03-04 231609.png

the condition fails.

Troubleshooting already attempted

I tried several approaches to normalize the values:

  • .trim

  • .asString

  • .asJsonString

  • storing values in variables before comparing

  • checking for hidden whitespace

  • using .toString

None of these resolved the comparison failure.

Additional observation

The value from customFields is stored under a dynamic key (custom field ID):

"customFields": {
  "69a18668c0386b0f42a6cbb5": "69a1866ec0386b0f42a6cbb6"
}

So I suspect Automation may be treating this value differently (e.g., JSON node vs string), even though the output appears the same.

Question

Has anyone encountered this behavior when comparing values retrieved from:

  • a regular object property (id)

  • a map/dynamic key (customFields.<customFieldId>)

in Jira Automation smart values?

If so, what is the best way to normalize or reliably compare these values?

Any guidance would be greatly appreciated, as this comparison is a critical step in my automation workflow.

Thanks in advance!

1 answer

3 votes
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
March 4, 2026

Hi @Ramya R -- Welcome to the Atlassian Community!

Without seeing your entire rule and audit log for context...

Please note we have no idea what the audit log renderer does; that behavior is undocumented.  Thus, the log entry adder could be performing various text formatting and type conversions to display plain text in the log viewer, and so the may values appear the same even when they are not.

Some techniques I use in a scenario like this are:

  • Store the values in Created Variables; this will force them to text and reduce the chance of a racetrack timing problem from field / data accesses
  • When writing test values to the log, add "canary" indicators around the value to look for stray characters, and measure the length.  For example:
varMyValue: >>{{varMyValue}}<< has a length of: >>{{varMyValue.length()}}<<

With that logging in place, test again to observe any value differences.

 

Kind regards,
Bill

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events