Use Switch when one value can take several known values and each value needs a different path. Use Condition when the decision depends on ranges, several fields or compound AND/OR logic.
A Switch is easier to read than a staircase of nested Conditions, but only when every case compares the same input.
Fact-checked against current Microsoft Power Automate guidance on 24 August 2026.
A simple support-routing example
Suppose a SharePoint item has a Department choice with these values:
- Finance
- HR
- IT
The flow should send each item to a different team.
Build the Switch
- Add your trigger and retrieve the item.
- Add a Compose action that normalises the department value.
- Add Control > Switch.
- Put the Compose output in the On field.
- Add one case for each supported value.
- Add the actions for that route inside its case.
- Use Default for blank or unexpected values.
A useful normalisation expression is:
toLower(trim(coalesce(<department value>, '')))
Your case values would then be finance, hr and it.
The exact dynamic-content path depends on the trigger and column type. Run a test and inspect the raw input before writing the expression.
Always design the Default case
Default is not an afterthought. It is where renamed SharePoint choices, blanks and new business values surface.
A good Default route should:
- record the item ID and unexpected value;
- notify an owner who can fix the data or flow;
- avoid sending the item to a guessed destination;
- end with a controlled status.
Silently doing nothing makes the flow appear successful while the business item disappears.
Switch versus Condition
| Requirement | Better control |
|---|---|
| One status equals one of five text values | Switch |
| Amount is greater than 1,000 | Condition |
| Department is Finance and country is UK | Condition |
| One event type selects a processing branch | Switch |
| Several unrelated rules must all be checked | Conditions or a decision table |
Do not force ranges into dozens of exact Switch cases. Equally, do not nest five Conditions when all of them compare the same status field.
Common failures
A value never matches its case
Check spaces, letter case, nulls and whether the dynamic value is an object rather than text. Normalise once in Compose and switch on that output.
A SharePoint Choice value looks wrong
Inspect the trigger output. Some fields expose both an object and a text value. Select the actual choice value rather than the whole object.
Several cases need the same action
Put shared work after the Switch. Keep only route-specific actions inside cases.
The flow has too many cases
The process may need configuration data instead of hard-coded logic. A SharePoint routing table can map a business value to an owner or destination without editing the flow whenever the organisation changes.
Test the control properly
Test every named case plus:
- blank input;
- unexpected input;
- different letter case;
- leading and trailing spaces;
- a renamed source value.
The Default path should be as deliberate as the happy paths.
Microsoft sources
- Add conditions and controls to a cloud flow
- Use expressions in conditions
- Workflow expression functions
Make the decision logic easier to maintain
Bring a screenshot of the current branches and sample input to the Power Automate Builders Space.