nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Conditional Logic Smart Values Not working as Expected

Andy Chlup

I have an automation that I'm using form data to drive an automation:

I've tried to equivalent approaches, but get different results and I'm not sure why.

LogicTests

Case 1 - Variable

RedAdv = {{issue.forms.717a0542-5b22-4ed3-926e-b541c9eb5fd7.RegAdv.label.get(0)}}

{{if(equals(RegAdv,"Yes"),issue.forms.717a0542-5b22-4ed3-926e-b541c9eb5fd7.RegAmount,0)}}

It returns the value expected

Case 2 - Smart Value

{{if(equals(issue.forms.717a0542-5b22-4ed3-926e-b541c9eb5fd7.RegAdv.label.get(0),"Yes"),issue.forms.717a0542-5b22-4ed3-926e-b541c9eb5fd7.RegAmount,0)}}

It fails and returns 0

{{RegAdv}} and {{issue.forms.717a0542-5b22-4ed3-926e-b541c9eb5fd7.RegAdv.label.get(0)}} return the same value so the context seems the same.
Screenshot 2025-03-19 091835.png

Any idea why it only works with a variable and not a smart value?

Screenshot 2025-03-19 091650.png

Accepted answers

Bill Sheboy

Hi @Andy Chlup

First thing, I am just another Jira customer and have no internal knowledge of the automation engine's implementation. My suggestions are based on my experience and observations using rules. With that out the way...

Some data in rules is usually available when the rule starts (e.g., fields in a trigger issue) while other data is looked up just-in-time to improve rule performance (e.g., sub-tasks, form data, assets, third-party addon custom fields, etc.) This behavior can create side-effects / problems in rules where all of the needed data is not ready fast enough to do what is needed; that is, a racetrack error happens.

When your rule stores the form data in the created variable, that looks up the data to complete the expression before the next rule step happens.

But without the variable and inside the conditional expression, it may not be looked up fast enough before the condition's equals() function completes.

There is another, less likely, possible cause: perhaps form fields do not work inside the equals() logical condition function. Some smart values do not work with some functions, and there is limited documentation to explain when these situations occur.

Please note my "usually available" from earlier. Even standard issue fields may have this problem with some rule triggers. An example for Jira Cloud is the Issue Created trigger, where the rule can start before all issue data is "ready", potentially leading to errors and other weird behaviors. The mitigation for that symptom is to always add the Re-fetch Issue action immediately after the Issue Created trigger, slowing the rule a bit and reloading the data before proceeding.

Kind regards,
Bill

All comments

Bill Sheboy

Hi @Andy Chlup

When your rule stores the form data in the created variable, that looks up the data to complete the expression before the next rule step happens.

But without the variable and inside the conditional expression, it may not be looked up fast enough before the condition's equals() function completes.

Kind regards,
Bill

Andy Chlup

Thanks Bill.

I had a similar thought on timing, seen a number of cases where similar things happen.

Ludwig Einicke

Hi @Andy Chlup, hi @Bill Sheboy

After having my share of "fun" with automations and variables I can confirm (or at least strongly infer) that it is, indeed, a scope issue.

Smart values stop working as soon as you bury them inside a function. Your cases actually function as a good example for where the border lies:

Case 1: (working)

RedAdv = {{issue.forms.717a0542-5b22-4ed3-926e-b541c9eb5fd7.RegAdv.label.get(0)}}

The smart object gets read and interpreted correctly, as it isn't "layered" into anything else.

Case 2: (blurred lines)

{{if(equals(RegAdv,"Yes"),issue.forms.717a0542-5b22-4ed3-926e-b541c9eb5fd7.RegAmount,0)}}

The Variable "RegAdv" is in-scope, because it was defined inside the same automation and gets read correctly because of that. The Smart Value gets read correctly aswell (I am actually positively surprised this works). This might be a special case as I have encountered functions where "the smart value being inside of a function" will already cause the scope to narrow down and deny correct interpretation and/or issuefield lookups of the smart value.

I have noticed that this is actually improving over time. Atlassian seems to be doing some work in the background to extend smartvalue functionality inside functions.

Case 3: (not working)

At some point the smart value gets nested "too deep" to get correct interpretation and/or access to issuefield lookups:

{{if(equals(issue.forms.717a0542-5b22-4ed3-926e-b541c9eb5fd7.RegAdv.label.get(0),"Yes"),issue.forms.717a0542-5b22-4ed3-926e-b541c9eb5fd7.RegAmount,0)}}

Where this exact point is seems to vary across functions (see above). Here it is a clear case of: The "equals" function tries to look up a variable named "issue.forms[...]", gets confused and stops trying. I personally think that it simply has no way of interpreting the input as smartvalue and will always try to find a variable with the same name defined inside the automation run first after interpreting it simply as string. I have no way of confirming that though. We can also view it as out of scope because either way, there is no way for the "equals" function to access issuefields for the direct inputs we give it.

Workaround:

I have come to enjoy using a LookupTable where I first read all the inputs (especially issue fields, trigger-information etc.) I need during the execution of my automation first and use as few as possible {{issue....}} smartvalues afterwards (of course there are cases where this doesn't completely work but i tend to at least try to bundle up as much as I can). This has a few advantages:

Lookuptable-Name: myTable
Key1 - Value1: myKey1 - myValue1
Key2 - Value2: myKey2 - {{issue.forms.717a0542-5b22-4ed3-926e-b541c9eb5fd7.RegAdv.label.get(0)}}
Key3 - Value3: Yes - {{issue.forms.717a0542-5b22-4ed3-926e-b541c9eb5fd7.RegAmount}}
Key4 - Value4: Default - 0

- Lookuptables can store A LOT of key-value pairs, saving space compared to single variable creation

- They can be accessed like Smart Values and they do have a function for accessing values aswell that works inside most functions I have encountered to far (at least in way more cases than the issue-smartvalues):

Input - Return:
{{mytable.myKey1}} - myValue1                 -- Like Smartvalue
{{mytable.get("myKey1")}} - myValue1          -- With get-Function and String-input
{{mytable.get(RedAdv)}} - [depends on RedAdv] -- With get-Function and Variable-input

- The key-value pair can be accessed Dynamically (needs a variable to work though)

For your case (which doesn't need a LookupTable, just to be clear):

Create Variable: RedAdv = {{issue.forms.717a0542-5b22-4ed3-926e-b541c9eb5fd7.RegAdv.label.get(0)}}

Create LookupTable: myTable (see above)

Log action: {{RedAdv}} | {{myTable.get(RedAdv)}}

-- only if needed: Conditional Block: If {{RedAdv}} equals "Yes"

Add Comment to issue: {{myTable.get("Yes")}}

Hope this helps you and everyone coming here from googling problems aswell.

For further reference, the following lookup as Table-Variation from your second Case would work aswell:

{{if(equals(myTable.get(RedAdv),"Yes"),issue.forms.717a0542-5b22-4ed3-926e-b541c9eb5fd7.RegAmount,0)}}

Fun implementation alternative for the "Add comment to issue" Block (I should work but i haven't tested it):

[...]
Add Comment to issue: {{if(equals(myTable.get(RedAdv),"Yes"),myTable.get("Yes"),myTable.get("Default"))}}

This might save some runtime as there is no second "loading in of issue fields" required (the effect should be minimal for this simple case).

EDIT1: Spelling and further referecnce-section

EDIT2: Syntax-Correction

Kind regards,

Ludwig

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-service-management-cloud

jira-service-management