A single SharePoint update produces a stream of Power Automate runs. Each run writes back to the same item, creating another change that starts the flow again. This can look like a duplicate trigger problem when the workflow is actually generating its own input.
Before increasing capacity or deleting runs, identify the business event that should qualify for processing and which updates the automation itself performs. The remedy should stop unintended repetition while preserving legitimate work.
Original conceptual illustration of a self-triggering workflow and an eligibility gate, not a Power Automate screenshot.
Trace the update that starts the next run
Pick one synthetic or sanitised item and compare its run history, modified fields and timestamps. Establish whether another user, another flow or this flow changed it. Record any emails, approvals or external writes already produced before retrying the item.
Microsoft’s Power Automate anti-pattern guidance identifies infinite trigger loops as a design risk and recommends conditions that prevent a flow from repeatedly initiating itself. A warning deserves investigation; it is not evidence that every update-triggered flow is inherently wrong.
Define an eligible transition
“Whenever this item changes” is often broader than the commercial requirement. The business may want an action only when a request becomes ready for review, or when an approved record has not yet been exported. Write that rule in business language before implementing an expression.
Document what happens after success, after failure and after a genuine correction. A permanent “processed” flag can stop repetition but may also hide a valid later update. If a record needs reprocessing, agree an explicit version or rework route rather than having staff toggle fields until something runs.
ITZ’s Power Automate solutions service can review the trigger and state changes. Review Your Automation Trigger Loop with the flow purpose, affected trigger and a sanitised run example.
Distinguish a trigger condition from a later check
Microsoft’s trigger-condition documentation explains that conditions on the trigger can avoid a run when its requirements are not met. A Condition action placed later in the flow instead evaluates after the run has begun. Choose the mechanism deliberately and test the actual connector payload and field names.
A gate alone does not make downstream actions safe to repeat. Concurrent runs may both observe an eligible state before either records completion. Review concurrency and operation identifiers where appropriate, especially for actions creating customer records or sending notifications. The safe-retry guide addresses that separate duplicate-side-effect problem.
Contain the problem without losing the work
If a live loop is creating harmful side effects, an authorised administrator may need to pause the affected flow under the incident process. First record the flow identity, business owner, queued work and known side effects. Pausing does not undo completed actions or prove that an external system has stopped processing.
Agree how legitimate requests will be handled during the pause and how the backlog will be reconciled. Do not casually replay every historical run: an earlier attempt may already have completed part of its business action.
Test the positive and negative paths
- Make an irrelevant edit and confirm that the business action does not occur.
- Make an eligible transition and verify the intended action and completion state.
- Allow the automation’s own bookkeeping update and confirm it does not start another business action.
- Submit a legitimate later correction and verify the agreed reprocessing route.
- Simulate a failure and a closely timed second change, then inspect run history and the destination for duplicate or missing work.
Check both the trigger history and the actual destination. The completion-monitoring guide explains why a run status alone is not the complete business outcome. Preserve ownership and recovery responsibilities using the automation handover checklist.
Review Your Automation Trigger Loop
Bring the intended business event, fields changed by the flow and a sanitised run sequence. ITZ can discuss eligibility, state transitions, duplicate protection and acceptance tests. Review Your Automation Trigger Loop through the contextual form below.
Microsoft documentation reviewed on 8 November 2026. Proposed tests do not describe a verified client deployment.
