Inconsistency using comparison smart values with Assets

[David Foote]

Hi all,

I'm running into an issue pulling data from Assets and using smart value comparisons.

Using the "Lookup Objects" action, I'm getting a record out of Assets. Then, I want to look at the value of a select field and see if it equals a string (in this case, "Fixed").

What I'm noticing is that if I do a direct comparison using the {{lookupObject.first...}} smart values, it always evaluates as false.

So, this line will always return false no matter the actual value:

{{equals(lookupObjects.first.First Level Approval, "Fixed")}}

However, if I save that value to variable first, it works just fine.

So, I create a variable called firstLevel and assign it the value of

{{lookupObjects.first.First Level Approval}} 

and then use the following smart value, it compares correctly and will return appropriately

{{equals(firstLevel, "Fixed")}}

Here is screenshot of an automation I used to test this and the resulting output

Any suggestions would be appreciated!

[David Foote · Accepted solution]

It looks like this is a known issue that affects list, text and math functions along with conditional logic when working with Assets:

https://support.atlassian.com/jira/kb/workaround-for-using-smart-value-functions-with-assets-data-in-automations/

The workaround is apparently to save to a variable - so good to know I guess!

[Bill Sheboy]

Hi @David Foote 

First, a disclaimer that I am not using Assets with JSM, and thus my suggestions are based upon what I know about rules in general.  With that out of the way...

Some smart values' content are looked up just-in-time when the rule needs them.  One example of this {{issue.subtasks}} and I believe Assets are the same.  And...some rule processing has timing problems where any slowdowns can cause problems / racetrack errors.  Thus for the example you show, I hypothesize the Asset value is not looked up fast enough before the comparison occurs, leading to a comparison of null to "Fixed".  But when it is stored in a variable first, the value is completely evaluated and stored before it is later needed in the conditional check.

Another possible cause is field typing.  When something is saved in a variable, the text representation of it is used to store it.  But inside of the conditional expression, perhaps an identifier or pointer is being compared to the text "Fixed".

Ultimately, I believe the Atlassian Support team would be able to explain which of these (or another cause) is leading to this symptom: https://support.atlassian.com/contact/#/

Kind regards,
Bill