Power Automate - Switch, Condition and If()

The if statement is the most ubiquitous expression in all programming, with it being the foundation of all code. With it being so fundamental Power Automate has more than one way to solve any condition logic. The key is to know them all and when to use them.

1. If Expression
2. Basic Condition
3. Escape Condition
4. Switch
5. Run After

1. If Expression

The if expression is still underutilised in Power Automate, it really should be the first condition you go to.

if(equals({variable},'value'),'It matches','It doesn't match')

It should be used whenever an input is a condition. I see far to often a condition action to set a variable which is then an input to another action. In these cases, we can move the condition within the input, making the flow simpler, easier to understand and use less api calls.
Whats also great is it can be as complex as you need

if(
    or(
        equals(triggerBody()['text'],'value')
    ,
        and(
            greater(triggerBody()['number'],10)
        ,
            contains(triggerBody()['text_1'],'Test Phrase')         
        )
    )
,
    'It matches'
,
    'It doesnt match'
)

2. Basic Condition

This is the one that everyone goes to and is used more often than it should be, but it does have it uses. Its great for one scenario, if there has to be 2 different actions taken on a condition, e.g. if true add, if false remove.

The key thing to remember is:

• It shouldn't be used to set a variable (use the if expression)
• Only the differences should be in the condition (i.e. move shared actions above/below the condition)

Incorrect Condition

Correct Condition

The above may require different email bodies, but that's when we should use the if expression for the body input.

3. Escape Condition

What's an escape condition I hear you ask, well it's not an actual unique action but the way we use a basic condition. Conditions should not be used as branching, is should always re-join into a single branch. But you may have certain conditions that require no further actions, often people will let the flow branch out so that the flow can run through conditions to the end of the flow. What we should be using is an escape condition, the condition is used to decide if we terminate or continue.

Escape conditions make understanding a flow easier, as it removes nesting and follows the 'fail fast' philosophy, i.e. it ends straight away rather then running the length of the flow.

Incorrect Conditions

Correct Conditions

Because the above are over simplified it may not show the full benefits, but if the flow was scaled up the top conditions would be a lot harder to read.

4. Switch

The Switch is often neglected by developers, with nested ifs far to common. (It has even been neglected by Microsoft Developers as it is the only action still using v2 definition). Although its use cases are limited, it still should be used ahead of other conditions in the right situation. Though it does have a couple of drawbacks when using it:

• It can be hard to read as it gets very wide
• It can only do simple comparisons

You can get around the second issue, with a little creativity.

Lets say you want 3 switches

• Value = first
• Value = second
• Value = third and Value2 = 1

What we can do is use the if expression within the Switch On. That way we can concatenate values to create unique strings.

We use below formula to create our unique values

concat(
   triggerBody()['text']
,
   if(equals(triggerBody()['number'],1),1,'')
)

• Value = first
• Value = second
• Value = third1

5. Run After

The final way to do a condition is using the Run After conditions. Very much in the line of JavaScript Try,Catch,Finally error handling.
With the combination of parallel branches and Run After conditions we can build another type of condition.

This condition should only be used as a last resort, where in flow logic cant be used. A good example would be if you are updating an item in a database, if the item is missing then you create the item. A better approach would be to check if it exsists first, but not all connectors/api's may have that functionality.
For further exception handling see exception-handling