Trigger Conditions in Power Automate: Stop Flows From Running When They Should Not

Most noisy flows are not slow because the actions are complex. They are slow because they start when they should not start at all. Trigger conditions fix that by evaluating a true-or-false expression before the run is created, which saves run history noise, API calls, and quota.

Trigger conditions belong at the gate

A trigger condition is evaluated before the flow instance starts. You add it in the trigger settings, not as a normal Condition action. If the expression returns false, Power Automate skips the trigger and does not create a full run.

That distinction matters. A Condition action still creates a run, consumes trigger capacity, executes trigger plumbing, and adds another green or gray entry to the run history. A trigger condition prevents that work from happening.

Pattern	Trigger condition	Condition action
Stops the run before creation	Yes	No
Appears as a skipped trigger	Yes	No
Can use later action outputs	No	Yes
Best for cheap eligibility checks	Yes	Sometimes
Best for branching inside a process	No	Yes

Use trigger conditions for eligibility. Use normal conditions for business branching after the run has started. If the flow should not exist unless the item status is Ready, put that rule on the trigger.

Field checks should be explicit and boring

The most common trigger condition checks a field value. In SharePoint, Dataverse, and many connector triggers, triggerBody() contains the changed record payload. The designer may show dynamic content labels, but the expression should reference the real internal field name.

Only run when a SharePoint item status equals Ready:

@equals(triggerBody()?['Status']?['Value'], 'Ready')

Only run when a text field contains a value:

@not(empty(triggerBody()?['CustomerEmail']))

Only run when a numeric amount is greater than zero:

@greater(float(triggerBody()?['Amount']), 0)

Be defensive with optional values. The safe navigation operator in triggerBody()?['FieldName'] prevents failures when a field is missing or null. Trigger conditions should be boring because they are hard to observe compared with normal actions.

Modified-item flows need a stricter rule

The SharePoint when an item is created or modified trigger fires for every save. That includes user edits, flow updates, migration tools, and sometimes calculated metadata changes. Without a gate, your flow can update the item and immediately trigger itself again.

Use a process flag such as AutomationStatus, a modified-by check, or a combination of both. A common pattern is to run only when the business status is ready and the automation status is blank or Pending.

@and(
  equals(triggerBody()?['BusinessStatus']?['Value'], 'Ready for processing'),
  or(
    empty(triggerBody()?['AutomationStatus']),
    equals(triggerBody()?['AutomationStatus']?['Value'], 'Pending')
  )
)

Do not rely only on trigger frequency. A five-minute polling interval reduces how often the problem appears, but it does not fix the logic. A correct trigger condition makes the flow ineligible after it updates the item.

Multiple conditions are combined with AND

When you add multiple trigger condition rows, Power Automate treats them as all required. Every expression must return true. That is useful for simple independent checks, but I prefer a single @and() expression for anything non-trivial because it keeps the logic in one place.

Scenario	Expression shape	Notes
Status equals Ready	@equals(...)	Best first filter
Modified by not service account	@not(equals(...))	Helps skip system updates
Required field exists	@not(empty(...))	Prevents null action failures
Two required rules	@and(..., ...)	Easier to copy between environments
Either of two statuses	@or(..., ...)	Keep values exact

Skip updates made by a service account:

@not(equals(triggerBody()?['Editor']?['Email'], 'svc-flow@contoso.com'))

Only run for new items that have not been processed:

@and(
  equals(triggerBody()?['{IsFolder}'], false),
  empty(triggerBody()?['ProcessedOn'])
)

Keep expressions small enough to review. If a trigger condition becomes a page of nested logic, move some of the decision into a maintained field such as ReadyForAutomation. The trigger condition can then check one reliable boolean.

The reference syntax is easy to confuse

In trigger settings, paste expressions with the leading at sign. The classic expression editor may show examples using @{triggerBody()} in other contexts, especially when composing strings. For trigger conditions, the final condition should be a boolean expression like @equals(...).

This is valid as a trigger condition:

@equals(triggerBody()?['Priority']?['Value'], 'High')

This shape is common inside text interpolation, not as the whole trigger condition:

@{triggerBody()?['Priority']?['Value']}

Remember the return type. The condition must evaluate to true or false. If you paste a field reference that returns text, the trigger condition is not doing what you think.

Debug skipped triggers by proving the payload

Skipped triggers are quiet by design. That is the point, but it makes debugging different. Temporarily remove the trigger condition, run the flow with a test item, and add a Compose action that outputs the field path you plan to use. Confirm the internal field name and value shape, then put the condition back.

When a trigger condition does not fire, check these items:

1. The field internal name, not the display name.
2. Choice and lookup fields, which often require ['Value'].
3. Person fields, which often expose ['Email'] or claims.
4. Null handling for optional values.
5. Multiple trigger condition rows that are accidentally too strict.

Use a temporary diagnostic branch, not guesswork. Capture the trigger body once, inspect it, and write the expression against the actual payload. After validation, remove the diagnostic action so the production flow remains clean.

Trigger conditions are one of the highest-leverage features in Power Automate because they prevent bad work instead of handling it later. Put eligibility at the gate, keep the expression defensive, and your run history will show real business events instead of automation noise.