If/Else If vs Branch Clarification

[Quinn Campbell]

I would love if someone could clarify for me a few things on filtering an automation rule. 

I am not a programmer so please excuse if my question is rudimentary. 

When a rule is triggered and there is an "If" that doesn't meet the "If" filter I understand the automation will not continue on that path. If there is an "else-if" after that the 1st "if" then it will evaluate weather it should continue or not. All of that's fine.

If both "if/else if" fail, will the automation continue on the original path to rules/actions that were below/outside that "if/else if" branch or does it always do both paths after the "if/elseif" path anyway? Basically does an automation always continue on the original path along with if/else if branches or does it only follow and end on an if/else path if it can?

Branch vs If

How does a branch differ from an if/elseif tree with the first brand element being an if statement? When is the best time to use a FOR Each: Add a branch?

Example I am working through. I am making an onboarding automation with a rule that has different set of tasks depending on which team the employee is being hired to. The 3 options I see are

Is the use of a bunch of if statements

if=teamA

if=teamB

if=teamC

vs

use a single line of if/else if's

If=TeamA, elseif =TeamB, elseif =TeamC

vs

Branch everything

Branch - =TeamA

Branch - =TeamB

Branch - =TeamC

[Mikael Sandberg]

Regarding your If/Else question, if you you have other components below the If/Else the rule will run those even if none of the If/Else conditions are true. Example if you have a rule that looks something like this, the edit issue fields would still be done even if the If/Else would not be true.

Branching is used to execute actions on related issues, for example if the triggering issue is an epic and you want to close any linked issues if the epic is closed then you will use the branch to close those linked issues.

Hopefully this explains the difference between If/Else and branching.

[Bill Sheboy]

Hi @Quinn Campbell 

Yes, and...to Mikael's explanation: another difference between if / else and branching is the order of execution of rule steps.

With an if / else block, the steps occur in the order you wrote them in the rule.  After the if / else block completes, then steps after the block continue.

However with a branch that is on more-than-one-issue, each item is processed in parallel, in no defined ordering.  There is no guarantee of when the branch will finish...up until the last step of the rule.  This helps improve rule performance...and it requires us to think differently when writing rules.

For example:

• trigger: some trigger
• action: some action
• branch: on several issues, such as with JQL
  • action: some action inside the branch
• action: some other action <<<== This action will likely happen before the above branch completes.

Kind regards,
Bill

[Quinn Campbell]

Thank you all for the replies. Definitely helpful.

What are the pros and cons of doing a bunch of ifs in separate forks rather then if/else if/else if/else if in a single fork?

Visually it would probably be easier to organize on the Jira layout if I did a bunch of independent ifs. 

the only thing I can think of off hand is that multiple ifs in separate forks were true they they'd be run simultaneously while if/elseif/elseif/elseif would be run/evaluated in order. Is that correct? Anything else? 

[Bill Sheboy]

Yes, that is correct about the sequential vs. parallel processing.

Your specific solution needs drive what is better / worser as approaches:

• When the processing is different for each "thing", the if / else conditions may be better.  Rules have a 65 component limit, so a rule could run out of space when there is lots of variation.
• Branches help when there are an unknown number of things to process, from 0 to up to 100
• When the same thing needs to be done, but with different data, another option is to use Lookup Tables.  For example, let's say each "team" had a different value to set for a field like Labels; the lookup could provide that with no need for conditions or branches.

[Quinn Campbell]

Lovely, thanks so much!