A flow built on SharePoint's "when an item or a file is modified" trigger runs twice for what felt like one edit. Someone updates a status column through Quick Edit and the run history shows two executions logged seconds apart, or a colleague is co-authoring a Word document with AutoSave on and every incremental save fires the flow again. The fix is a setting on the trigger itself, not a Condition action further down the flow.
How to do it
- Open the trigger and select Settings.
- Under Trigger Conditions, select + Add.
- Write an expression that only evaluates true when the column you actually care about lands on the value you're watching for, not just any touch to the item. Every expression starts with
@:
@equals(triggerBody()?['Status']?['Value'], 'Ready for Review')- Need more than one filter? Select + Add again. By default every condition must be true; for either/or logic, wrap them in
@or(test1, test2)instead of stacking separate conditions. - Save the flow, then deliberately cause the noise you're trying to filter: a multi-field Quick Edit save, or a document left open with AutoSave running for a minute. Check run history. Nothing should appear until the column you're watching actually changes to the value in the condition.
Why it works
Trigger conditions are evaluated before a flow instance is created, not after it starts. A Condition action placed inside the flow still counts as a run, it just exits early once the condition fails, and that run still lands in your history and against your environment's request limits. A trigger condition that evaluates false stops the flow before a run exists at all, so an AutoSave tick or a field write that doesn't touch your tracked column produces nothing to look at, rather than a run you have to explain.
When not to use it
If the flow genuinely needs to react to any change to the item, not just one column, trigger conditions won't help. They only ever see the trigger's own snapshot of the item, not what specifically changed since last time. For that, drop the "Get changes for an item or file (properties only)" action right after the trigger instead, and branch on its per-column "Has Column Changed" outputs.