by There are times where we have multiple possible values, and we want to have different workflows for each. Think in the case of a category. If it’s a category “A,” you will do something; if it’s “B,” do another. We can do the same with nested Condition Actions, but it’s quite cumbersome and not very user-friendly. It’s much better to have the conditions side by side and parse them individually, and for that, we have the Switch Action.
Where to find it?
You can find it in the Switch Action in the “Control” tab.
Then select the Switch Action.
We’ve already covered the “Apply To Each” and “Condition” actions in the past, so if you have questions, you can check their individual references.
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
You can use it by defining what you want to compare and then the cases.
Add the cases that you need by pushing the plus button. The default is always present, but more on that in the recommendations below.
Types
Flow does a nice job of keeping things consistent. If you define a variable of the type int and have a case with “case 1”, Flow will return an error when you try to save. Even with this safeguard, you should always make sure that you use the same types in all cases.
Limitations
You can’t add comments to each of the “cases.” It’s a pity since it would provide a lot of information, but I’m sure Microsoft will tackle this one eventually.
Also, you can’t define dynamic values in the “case,” so all values need to be defined when you’re building your Flow.
Finally, you can only add 25 cases. You can add up to 27 until the UI stops you, but you’ll get an error message if you do so.
As you can see above, the plus is greyed out, but we managed to add 27 elements.
Common Errors
Here are some common errors in a Switch.
Different Types
The template validation failed: 'The template action 'Switch' at line '1' and column '896' is not valid: the expressions specified for 'case' properties in switch cases evaluate to values of different types 'Integer, String'. Expressions in case properties should evaluate to values of the same type.'.
This error occurs when you’re trying to compare two different types. For example, if you have an Int variable but have choices that are strings.
Recommendations
Here are some things to keep in mind.
Don’t use nested Conditions unless…
There’s only one reason to use nested conditions. Since the Switch Action expects an exact value to be provided, it’s impossible to do complex conditions to validate a path. In this case, follow the rules in the Condition Action Reference so that you don’t get into trouble.
Please keep it to a minimal
Having many case expressions is easy, but don’t go overboard. Try to keep it to a minimum since it may impact performance if you have many cases.
Don’t duplicate
Also, it’s hard to re-use code if you have many cases. You’ll eventually copy and pasting code from one case to another if you have 2 cases with the same actions. If this happens, validate the data before with a Condition Action and then let the rest of the data be validated by the “Switch Action.”
Use the default but don’t nest.
If you have a lot of values, please break them down into multiple actions. I’ve seen people using the default as the “bucket” where all the other values are sent so that you can provide another “Switch Action” to parse them. This makes for a very hard-to-debug Flow and should be avoided at all costs.
Define all cases
Still in the default, don’t use the default to group actions. For example, if you have conditions that behave differently for 2 and 3 but 1 and 4 are the same, don’t use the default for actions 1 and 4. In the future, if things change and you have a 5, it will be parsed in the default, and it may result in invalid data since your Flow won’t fail when this happens.
Use the default for unexpected cases.
The ideal usage for the default is for unexpected cases. If you define all the cases you expect, you should get a warning if the default is triggered. This will enable you to check changes in the data, bugs and adjust your Flow accordingly.
Name it correctly
The name is super important in this case since we’re defining a value to parse. Always build the name so that other people can understand what you are using without opening the action and checking the details.
One suggestion is to name it as a question. Then it becomes quite readable.
“What’s the value on case 1?”
Always add a comment.
Adding a comment will also help to avoid mistakes. Indicate, for example, the type of data that you expect and the potential exceptions. It’s important to enable faster debugging when something goes wrong.
Always deal with errors.
Have your Flow fail graciously when the file doesn’t exist and notify someone that something failed. It’s horrible to have failing Flows in Power Automate since they may go unlooked for a while or generate even worse errors. I have a template and a template that you can use to help you make your Flow resistant to issues. You can check all details here.
Back to the Power Automate Action Reference.
Photo by George Bakos on Unsplash
