by I can say with confidence that the condition action is one the most used actions in Power Automate. It’s simple in nature and instrumental in any Flow. It receives an argument, and, based on your conditions; the Flow will go in one direction or another. The condition action is the equivalent of “If” in any programming language or tool (like Excel, for example).
Where to find it?
You can find it in the “Built-in” section under “Control.”
If you don’t see it right away, you can click the “Control” section, and you’ll see it right above the “Apply to Each.”
Power Automate tends to save the most common actions on the main screen, so check there before going through the full hierarchy.
Also, you can use the search to find it quickly.
Usage
Here’s how it looks like:
Microsoft did a great job in displaying it. If the condition is true, then it follows the “green path,” and if not, it follows the “red path.”
Please consider the colors as indicative. They should not represent the “correct” or “incorrect” path to follow. Sometimes you want things that “don’t” fit the condition, so use them as they make sense for your Flow.
You can use one or more conditions (more on that later), but I want to explain the first 2 essential parts:
- The type of the data
- The operators
Let’s check each one individually.
Types
You can use all types to compare and combinations each one. For example, you can have on the right side a string and on the left an Integer, but it’s hard to think of an example where that’s useful. Here’s an example of a comparison between 2 types:
In this example, we have a variable that is an array, and we create another one to compare.
Almost always, the result will be “false,” so ensure that you’re using the same types for comparison. Let’s look at the following example that can be misleading:
In this case, we have a string with the value “5” and the number 5. We would expect the comparison to be “true,” but it’s not.
Flow compares based on the type, and the types are different, so the return is always “false.”
Operators
For you to be able to make a comparison, you need operators.
All of them are common for all types, so you should understand that, for some types, operators may not be as useful. For example, the “greater than” operator may not be useful for strings, but it’s common for Integers or Floats.
Formulas
You can define formulas on either side of the condition action. For example, let’s say that you want to check if a date is lower than today. To do you need to:
You can use the utcNow function to achieve that, with the operator “is less than.”
Now let’s check if a string is bigger than 100 characters.
To do this, you can use the length function on the string and have the operator “is greater than.”
These two examples show you how to compare items from 2 different types, transform one of them, and then compare.
Multiple Conditions
With all of the above, you can even add multiple conditions. We’ll separate them into:
- New rows
- New groups
New rows enable you to add a condition aggregated either by an AND (all of them need to be true) or an OR (one of them needs to be true). It’s mighty, and you can add as many as you want.
To do that:
Then add the conditions.
On the other hand, we have groups. Think of them as units that return a result that is combined with the other groups or rows.
There are 2 ways to create a group. The first one is to select the option “Add group.”
Then you can add new conditions as follows.
If you already have conditions created, you can select them and then create a group.
The result will be the same.
Limitations
The biggest limitation is that both sides need to be of the same type. If not, even if the data is the same, the condition action will return “false.”
Recommendations
Here are some things to keep in mind.
Ensure you’re using the same type
Ensure that both members use the same type. Even if the values are the “same,” the comparison will return “false” since they are different types. Some functions convert the values, like the int function, for example. Please be careful, especially when you get data from the user or an outside API.
Name it correctly
Power Automate uses the names of the actions to reference them in other parts of your Flow. If you have a “Condition” name, you’ll reference it with that name, and that’s not useful. Always define the name, indicating the purpose. Then, regardless of what you’re doing, you always know where the data comes from.
Always add a comment.
Having only a “good name” is not enough. It’s important to have a description of the condition’s purpose and what you want to test. For complex Flows, you’ll have an easier time debugging it if you know your initial purpose.
Add the comment before you start adding tasks. This will force you to think ahead of time. In the future, when you’re searching for an error, you’ll know “why” you added the condition action in the first place.
Here’s how to do it:
Keep the number of conditions to a minimal
Although you can add as many conditions as you want, I would recommend adding the minimal possible. It’s better even to break it down into multiple condition action than to have a huge one. This is because, when running, you’ll only get “true” or “false,” so if the result is not what you’re expecting, you don’t know what row is incorrect or even if there are multiple ones that need to be adjusted.
Keep the groups to a minimal
The same logic applies to the groups. It will be hard to debug if you have many groups if the result is not what you’re expecting. If you can, split them into multiple condition actions to control the results.
Back to the Power Automate Action Reference.
Photo by Patrick Federi on Unsplash
Very helpful. Thanks !