Why Automation rules with IF ELSE may need several executions to work

[#1]

Hi Community!

I'd like to share with you all this recent KB article we published on Automation's IF / ELSE Block Condition:

• Scheduled Automation rule with IF ELSE Block Condition not working as expected in Jira
  
  

The diagnosis is simple yet can drive one mad 🤯:

• The Automation rule is triggered by scheduled JQL
• There are IF / ELSE blocks that we expect to be all executed but aren't
• It takes several consecutive executions for the rule to work fully as expected

If you've checked ✅ for all three items above, you may be expecting the IF / ELSE to work as we're used in programming languages — but the scheduled JQL trigger has some unique perks...

Take this example:

IF (condition A)
    THEN action A
ELSE IF (condition B)
    THEN action B
ELSE IF (condition C)
    THEN action C
ELSE
    THEN action D

Say our trigger JQL fetches 10 issues: 3 meet condition A, 2 meet condition B, 4 met condition C and 1 meet none.

You may expect that with a single execution, 3 issues have action A applied, 2 have action B, 4 have action C and 1 has action D, but what happens is that 3 issues will have action A applied.
And that's it!

On a second execution, if there are no issues that meet condition A, then it goes to the ELSE and applies action B to 2 issues.

On the third execution, supposing no new issues meet condition A or B, it applies action C to the 4 issues, and so on.

What happens is that the IF / ELSE is applied to the whole set of issues that the trigger JQL fetched. If a condition is non-empty, Automation goes through that path and, thus, not the others.
😉

We opened JIRAAUTOSERVER-209 to try and make the documentation a bit clearer on this.

So if you want all 4 conditions to be applied in the same Automation rule, you may do something like this (just an example) using the same IF / ELSE Blocks but without using the ELSE, just adding several IFs branching to each action:

IF (condition A)
    THEN action A

IF (condition B and not A)
    THEN action B

IF (condition C and not A and not B)
    THEN action C

IF (condition "not A and not B and not C")
    THEN action D

Try it out! See if it works for you!

Happy Jiraing! 😎

[Darryl Lee]

Cool. And to clarify, you have to use If/else blocks, not If: blocks right?

My experience has been that if an If: block fails, the rule stops then and there.

So then, this:

Not this:

[Rodrigo Martinez]

Hi @Darryl Lee 

Indeed! I just edited both the article and the KB! 🙇‍♂️

Here's a visual on how it'd work:

Cheers!

[Bill Sheboy]

Hi @Rodrigo Martinez 

I am curious why the issue you reference is a "suggestion" when this design choice seems more like a defect.  Would you please help the community of users understand this design choice?

This approach seems to make sense if the result set of a scheduled rule with JQL had to fully match the query or were treated as a batch in the rule.  But once the scheduled issues are captured, processing within the rule is one by one, processing through the logic.  Yes, there is asynch processing of those...but batch processing of them seems out of place and inconsistent: sometimes batch sometimes not.

For the cloud version, there is limited batch capability with {{lookupIssues}}.  For the server version, a scheduled rule with JQL provides this with {{issues}}.  The behavior you describe seems to be some overlapping behavior between versions, and a redefinition of common understanding of boolean logic.

Thanks in advanced for any clarity you can provide.

Best regards,

Bill

[Rodrigo Martinez]

Hi @Bill Sheboy 
Thanks for chiming in!

I've been trying to tackle your points but have rewritten it maybe a dozen times, sorry if I missed anything! 🙂

1. Suggestion

The "suggestion" is actually to improve the documentation, like making it clearer on this behavior. 🙂
Actually, the available issuetypes are bug and suggestion — I'd use "improvement" instead if it was available.

2. Issues captured

Actually, that's how Automation works: it fully matches JQLs and treat results in batch on every condition!
Mind, though: ACTIONS are performed in each issue (in bulk or individually), but CONDITIONS are nothing but JQLs disguised in a fancy look & feel, let's say.
There's a "JQL condition", but that's like the "advanced search" in Jira: it just allows you to get more creative into the query.

The TRIGGER/WHEN is always a JQL. On most cases it's just [key = JIRA-123], but on the scheduled trigger you can add your own JQL.
Then CONDITIONS only keep executing searches appending AND clauses to the initial search. The condition evaluates to TRUE if the search returns anything, and FALSE if it's empty.
The example below runs 2 JQL searches (supposing the comment as added to JIRA-123):

On WHEN: [key = JIRA-123]
On IF: [key = JIRA-123 AND status = Open]

I was 🤯 when I realized Automation Conditions are just JQL searches!
(This is also the reason why the rule fails if you delete an issue then perform any condition after it, but that's a topic for another article! 😅)

3. Processing within the rule is one by one

This is where I think we confound the most by our analogy of Automation to a programming language.
Maybe what we're discussing here is a LOOP STRUCTURE in Automation? This feature would allow to the filters/conditions execute separately over each issue.🤔

Let me know if any of it made sense!

Cheers!

[Bill Sheboy]

Hi @Rodrigo Martinez 

Thanks for your responses and explanations. I thought I understood which parts of automation rules executed non-deterministically (branches, racetrack conditions, etc.) and clearly there is more to learn. If nothing else, this post is leading me to pause on further rule usage for any non-trivial use cases until we can verify what to expect.

Best regards,

Bill

[Doug Levitt]

Thanks for the detailed explanation.  If I understand correctly, the If-then-Else condition for Scheduled Automations should be avoided.  As in most cases, it won't work as expected.

Now I wonder.  Is there an easy way to modify existing automations containing If-then-Else conditions.  From what I have seen, it's a PITA to do (using the interface).

Doug 

P.S. As a note, the title of this thread is very misleading.  It's not: "Why Automation rules with IF ELSE may need several executions to work".  Rather it should be: "Do not use IF ELSE in Scheduled Automations as it usually won't work".   The GUI should throw a warning message when this condition is selected, suggesting that it not be used.

[Rodrigo Martinez]

Hi @Doug Levitt 

Sorry guys! Both you and @Bill Sheboy! I really didn't mean to discourage the use or Automation or IF/ELSE but only to explain this caveat! 😅

It has it's uses, definitely! — but in simpler(?) conditions that maybe programmers aren't used to (we'd expect the IF/ELSE to be executed over each issue individually).

It still has that workaround, though, of having several IF/ELSE blocks in sequence. 😁

---

@Doug Levitt, I'm a little cautious as to say it doesn't work as expected. I'm more comfortable to agree that it may not work as expected to some people (prolly those with programming background?).

Also the title is from what I noticed to be the "end user experience" on such cases. Like, you'd expect the Automation rule to execute all Actions in all IF/ELSES (as if it'd iterate over issues individually), and that's only accomplished if you execute the rule several times in sequence. 🙂

---

I'm enjoying the discussion, folks! Happy to know the article was useful in some way! 😃

🍻 Cheers!

[Rodrigo Martinez]

Just another note:

As @Bill Sheboy brought up, it's with the Scheduled JQL trigger that the IF/ELSE may get confusing.

For all other triggers that only bring the (one) affected issue into the rule, it works like a charm! 😉

🍻

[Bill Sheboy]

@Rodrigo Martinez thanks again.  Such behaviors in automation rules are an example of why I suggested an improved documentation page, similar to the one for the REST API versions:

• All components/features on one page, and so more easily searchable
• Components identify applicable Jira versions for which they work (cloud, server, datacenter, etc.)
• Component examples are complete and usable with no changes/additions
• Errors, gotchas, and "this doesn't work like your understanding of If/Else" types of content
• No (or limited) links out to Java documentation which may not match how a feature was implemented in the automation engine.  (e.g. the RegEx implementation)

__Bill

[Bill Sheboy]

Hi @Rodrigo Martinez 

Just to check... Based on your description of the scheduled trigger with JQL--If/Else issue, I would hypothesize this also could happen for a branch with JQL that contains an If/Else.  Is that correct?

Thanks!

[Rodrigo Martinez]

Hi @Bill Sheboy 

Yep! The same would apply for branches — though IF/ELSEs aren't even available in branches in Server/DC yet (not sure about Cloud).

Cheers!

[Bill Sheboy]

If/Else is not available in branches for the Cloud version yet either; just asking in case they get added:

https://codebarrel.atlassian.net/browse/AUT-1005

Thanks, again!