Power Automate Trigger Conditions: The Run That Never Appears

A Condition action inside a flow is too late. The trigger has already fired, the run exists, and the check counts toward Power Platform request limits. A trigger condition is earlier. Microsoft's documentation is direct: if the condition is not met, the flow is not triggered, and no run history is logged. That is what you want for "only when status becomes Approved." It is also why the flow looks dead when the expression is wrong.

The expression is not a Condition card

Open the trigger, then Settings, then Trigger conditions. Each condition starts with @. If you add several, all of them must be true. Optional logic is one expression that uses or.

@equals(triggerOutputs()?['body/statuscode'], 1)

@or(equals(triggerBody()?['Status'], 'Approved'), equals(triggerBody()?['Status'], 'Rejected'))

The first form is the Dataverse-shaped one: a choice column often arrives as a number in the trigger body, not as the label on the form. The second is the shape you get from other connectors, where the field is a string. Neither is something to guess. Take the condition off, let one run succeed, and read the trigger output. Put the condition back using the property names and the types you just saw.

The ? matters. A path that does not exist then evaluates as empty, and equals against it is false, so the check is skipped. Without it, a missing property fails the expression. You still do not get a normal run to inspect. You get a trigger that is not doing what you think.

Where the skipped events go

Run history stays empty on purpose. The troubleshooting guide tells you to look at the trigger checks: a skipped check means the condition was not met and the flow was not started. If you expected a run, that is the place to confirm the event arrived and the expression rejected it. It is not evidence that the connector is down.

Two other filters sit next to this and are easy to mix up. A Dataverse trigger's column filter, covered in select columns, decides whether an update wakes the trigger at all. The trigger condition decides whether a wake-up becomes a run. A Condition action after that, including the scope pattern in try, catch, and run-after, only sees runs that already started. Use the trigger condition for the high-volume reject. Use the Condition action when both branches need to do something, or when you need the failed check written down inside the run.

A condition you can test

Write the expression in a Compose action on a flow that still has no trigger condition, and compare the Compose output to true or false against a payload you recognize. Then move that expression to the trigger. A condition that references the display name of a choice, or a column the trigger does not return, will look identical in the designer and will skip every event. The designer does not evaluate it. The next real row does.