Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

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

Hi Community!

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

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
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 Community Leader May 03, 2021

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:

Screen Shot 2021-05-03 at 7.10.12 PM.png

Not this:

Screen Shot 2021-05-03 at 7.10.56 PM.png

Like β€’ Rodrigo Martinez likes this

Hi @Darryl Lee 

Indeed! I just edited both the article and the KB! πŸ™‡β€β™‚️

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



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,


Like β€’ # people like this

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!


Like β€’ Bill Sheboy likes this

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,


Like β€’ # people like this

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).


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.

Like β€’ # people like this

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!

Like β€’ Bill Sheboy likes this

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! πŸ˜‰


Like β€’ # people like this

@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)


Like β€’ Rodrigo Martinez likes this

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?


Like β€’ # people like this

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).


Like β€’ Bill Sheboy likes this

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

Thanks, again!

Like β€’ Rodrigo Martinez likes this


Log in or Sign up to comment

Atlassian Community Events