How to Use Conditions in Power Automate Safely

A Power Automate Condition evaluates a rule and sends the run down either the If yes or If no branch. The important part is not drawing the branches. It is comparing values with the right type and deciding what blanks, unexpected input and failed actions should mean.

Fact-checked against current Microsoft Power Automate guidance on 24 August 2026.

Build a basic Condition

Suppose a SharePoint item has a Yes/No column named Approved.

Add the trigger that retrieves the item.
Select New step.
Add Control > Condition.
Put the Approved value on the left.
Choose is equal to.
Compare it with the Boolean value true, not the text word Yes unless the trigger actually returns text.
Add approved actions under If yes.
Add the rejection or no-action path under If no.

Run the flow and inspect the trigger output. SharePoint choice, lookup, person and Yes/No columns do not all return the same kind of value.

Compare like with like

Many Condition failures are type problems:

100 as a number is not always treated like "100" as text;
true as a Boolean is different from "true" as text;
a SharePoint Choice object is different from its displayed value;
a blank can be null, an empty string or a missing property.

Normalise the input in a Compose action when the source is messy. It is easier to debug one named expression than a large expression hidden in the Condition card.

Handle blank values explicitly

Use the empty() function when the rule is genuinely about missing data:

empty(<value>)

Use coalesce() when you need a safe fallback for a null value:

coalesce(<value>, '')

Do not turn every missing value into an empty string if null and blank have different business meanings.

Use AND and OR deliberately

For a request to proceed only when it is approved and has an owner, use an AND group.

For a priority route that accepts High or Critical, use an OR group.

Read the rule aloud before saving it. Nested groups can be logically correct but difficult to support. If the decision has many rows, consider a SharePoint configuration table or another explicit decision table.

Condition versus Switch

Use Condition for:

ranges;
comparisons between two fields;
AND/OR rules;
blank checks;
permission or status combinations.

Use Switch when one normalised value is compared against several exact cases.

Condition is not error handling

A Condition evaluates data from actions that ran. It does not replace Configure run after, Scopes or retry policies.

Use run-after settings to decide what happens when an action fails, times out or is skipped. Use a Condition to decide what a valid returned value means.

Common mistakes

The wrong branch runs

Inspect the raw value and its type in run history. Remove assumptions based on what the designer displays.

A blank field causes an expression error

Check for empty or null before calling functions that expect text, numbers or dates.

The flow has deeply nested Conditions

Move repeated normalisation into Compose, use Switch for one-field routing or put volatile routing data in a configuration table.

The flow succeeds but does nothing

Give the If no path a deliberate action, log or controlled termination. An empty branch can hide unexpected input.

Test set

Test:

one value that should pass;
one that should fail;
blank and null input;
wrong letter case where text is involved;
boundary values such as exactly 100;
an upstream action failure.

Microsoft sources

Get unstuck on the real input

Bring a redacted trigger output and the rule you intended to the Power Automate Builders Space.