Put each check at the right stage
Use a trigger condition when the trigger already has enough information to decide whether the flow should run. A Condition action chooses what happens after a run starts; it cannot undo that start. Separate trigger-condition entries act as AND; an or(...) expression lets you allow alternatives. A false trigger condition prevents a flow run, but the connector may still do work. See Microsoft's trigger-condition guidance.
Should this event start a run, based on data already in the trigger?
What should this flow do next, based on the data now available?
Example: an existing item is ready for review
In this invented scenario, Beacon Harbor tracks delivery reviews in SharePoint. A single-line text column has the internal name ReviewState and values Draft, Ready or Processed. Start with the modified-only SharePoint trigger When an item or a file is modified. This exercise handles existing items; it does not handle creation.
Select the trigger, open Settings and add this Trigger condition, including the leading @:
@equals(triggerBody()?['ReviewState'], 'Ready')Check the actual internal property name and trigger output in your test list. This expression expects plain text. Check the actual data before using it with a Choice or lookup field. See the equals expression reference.
Ready tells you the current value, not what changed. Editing the title tomorrow while ReviewState stays Ready still meets this filter. It does not prove that the previous state was Draft.
Check whether the relevant column changed
In an approved development list, enable versioning. Add Get changes for an item or a file (properties only) after the modified-only trigger. Use the same site/list and triggering item ID. Set Since to Trigger Window Start Token and Until to Trigger Window End Token. Leaving Until blank uses the latest version instead. See the SharePoint connector parameters.
Add a Condition after Get changes. Require both the returned changed flag for ReviewState to equal Boolean true and the trigger's ReviewState value to equal Ready. Select the changed flag from that action's dynamic content instead of guessing a JSON property path. Put a Compose containing “Ready for review” in the Yes branch. Do not add an action that changes data or sends a message to the No branch.
The change flag covers a time window that may include multiple edits. It does not show every previous and new value or detect changes to attachments or file contents. Microsoft explains versioning and these tokens in its SharePoint change guidance.
This check means “ReviewState changed in the window, and the trigger value is Ready.” To detect an exact Draft → Ready change, you need to track and test the history separately. Get changes produces its result after the run starts, so that result cannot be used in the same run's trigger condition.
Test ordinary edits, then rapid changes
For each ordinary case, make one edit and wait for it to finish processing before the next. Record item ID, edit time, trigger data, change window, selected branch and Compose output. Use invented data and leave emails, approvals and record creation out of this first test.
| Edit | Expected check |
|---|---|
| Create a Draft item | The modified-only trigger does not handle creation. |
| Edit a title while Draft | The Ready filter is false; no business action. |
| Change Draft to Ready | A run that meets the conditions should reach the Yes branch and Compose. |
| Edit only the title while still Ready, in a later isolated window | A run may start, but the ReviewState changed flag should be false; Compose stays skipped. |
| Change Ready to Processed | The current-value filter is false. |
| Change Processed back to Ready | A new qualifying change; decide whether another review is allowed. |
| Change state twice rapidly | Inspect actual window data. Do not assume every intermediate state appears. |
| Repeat a test with the planned business action | Check how duplicates are handled before replacing Compose with a real action. |
If the expected run is missing, investigate the expression, trigger input and connection. A trigger that skips a run is different from a flow that has already started. See Microsoft's trigger troubleshooting steps.
Treat loops and duplicates as separate problems
If a flow updates the same item it watches, that update may trigger it again. A Ready-only condition remains true if the flow leaves Ready unchanged. The later column-change check can skip the business action, but it cannot prevent a run that has already started. This example will not fix every loop. See Microsoft's guidance on self-triggering loops.
Before creating a review record or sending a message, decide how to identify the intended review. Use a consistent key and make the destination reject duplicates, or use another tested way to handle repeats safely. Separate “check then create” steps can both pass when runs overlap. Trigger filters do not guarantee that an action happens exactly once; see Microsoft's duplicate-run guidance.
In the handover notes, record what happens on creation, the field types, versioning, when repeat reviews are allowed and how failures are handled. Read the error-handling guide next, or use a workflow review to agree the rule before implementing it.
Technical sources checked September 25, 2026. The expression and tests are based on the documentation. We have not deployed this SharePoint flow or measured any reduction in runs.