Design a Flow That Avoids Infinite Loops: Mistakes to Avoid

An infinite loop in a Power Automate flow causes the flow to run repeatedly without stopping. This can consume your API request limits, slow down your environment, and trigger unwanted actions. The most common cause is a trigger that re-fires based on an action the flow itself performs. This article explains the typical mistakes that create infinite loops and how to design flows that stop when they should.

Why Infinite Loops Happen in Power Automate

An infinite loop occurs when a flow trigger is activated by an action that the same flow performs. For example, a flow that triggers on a new item in a SharePoint list, then updates that same item, causes the update to fire the trigger again. This cycle repeats until the flow hits a service limit or you manually stop it. The root cause is a lack of a guard condition that distinguishes between a user action and a flow action.

Power Automate does not automatically detect or block self-referencing triggers. The platform assumes that the flow designer has implemented proper logic to prevent re-triggering. Without that logic, any update to the same data source that the trigger watches will restart the flow. This is by design, but it places the responsibility on you to add the correct controls.

Steps to Design a Flow That Avoids Infinite Loops

Use the following methods to prevent infinite loops. Apply at least one of these techniques to every flow that updates the same data source it monitors.

Method 1: Add a Trigger Condition That Excludes the Flow Account

1. Open the trigger settings
   In Power Automate, select the trigger step. Click the ellipsis menu and choose Settings.
2. Add a trigger condition
   In the Trigger Conditions section, add an expression that checks the Modified By field. Use the expression: @not(equals(triggerOutputs()?[‘body/Editor/Claim’], ‘i:0#.f|membership|flowaccount@domain.com’)). Replace the email address with the actual service account that runs the flow.
3. Save and test
   Save the flow. Create a new item manually to verify the flow runs. Then update that item using the flow account to confirm the flow does not re-trigger.

Method 2: Use a Change Tracking Column

1. Add a Yes/No column to the list
   In SharePoint, add a column named FlowProcessed with the type Yes/No. Set the default value to No.
2. Modify the trigger condition
   In the flow trigger, add a condition that checks if FlowProcessed equals false. Use the expression: @equals(triggerOutputs()?[‘body/FlowProcessed’], false).
3. Update the column after processing
   At the end of the flow, add an action to update the current item. Set the FlowProcessed column to Yes. This prevents the flow from triggering again on the same item.

Method 3: Limit the Run Frequency

1. Open the trigger settings
   Select the trigger step and click Settings.
2. Set a maximum run count
   In the Trigger Conditions section, add an expression that limits the run count. For example, use: @lessOrEquals(triggerOutputs()?[‘headers/x-ms-workflow-run-id’], 1). This allows only one run per item.
3. Test with multiple updates
   Update the same item several times. The flow should run only once.

Common Mistakes That Create Infinite Loops

Updating the Same Item Without a Guard

The most frequent mistake is adding an Update Item action without any condition that prevents the trigger from firing again. If the flow updates the same list or library that started it, the update triggers a new run. Always add a condition, a change tracking column, or a trigger condition before the update action.

Using a Recurrence Trigger That Updates the Same Data

A scheduled flow that runs every minute and updates a SharePoint list can create a feedback loop if the update action modifies a field that the flow itself checks. Instead, design the flow to only update items that have not been processed. Use a filter query in the Get Items action to select only items where the status column is not Complete.

Ignoring the Modified By Field

When you update an item in SharePoint, the Modified By field changes to the account that performed the update. If the flow uses a service account, that account becomes the Modified By. A trigger condition that checks for the flow account is a reliable way to stop re-triggering. Many designers forget to include this check.

Not Using a Termination Condition in Do Until Loops

Inside a flow, a Do Until action can loop indefinitely if the exit condition is never met. For example, a loop that waits for a column to change to Approved will run forever if the column never changes. Set a maximum number of iterations in the Do Until configuration. The default is 60, but you can lower it to 10 or 20 depending on your scenario.

Trigger Type vs Scheduled Flow: Key Differences for Loop Prevention

Item	Automated Trigger (e.g., When an item is created)	Scheduled Trigger (e.g., Recurrence)
Loop risk	High — the trigger fires on every change, including changes made by the flow	Medium — the trigger fires on a schedule, but updates can still cause re-triggers if the flow runs again
Primary guard method	Trigger condition or change tracking column	Filter query in Get Items to exclude already-processed items
Run limit control	Trigger conditions and maximum run count	Recurrence interval and Do Until iteration limit
Best for	Real-time processing of new or changed data	Batch processing on a fixed schedule

You can now design flows that stop correctly by adding trigger conditions, change tracking columns, or run frequency limits. Start by reviewing your existing flows for any update action that targets the same data source as the trigger. Apply at least one guard method to each flow. For complex flows, combine a trigger condition with a change tracking column for double protection.