You created a SharePoint Power Automate flow that runs when an item is modified. The flow updates a column on the same list item. Instead of stopping, the flow restarts itself over and over in an endless loop. This happens because the update action in the flow counts as another modification, which triggers the flow again. This article explains why the loop occurs and shows you the settings to check and change to stop the cycle.
Key Takeaways: Breaking the Endless Trigger Loop in SharePoint
- Power Automate trigger condition “When an item is modified”: Add a condition to skip the trigger if the update came from the flow itself.
- Column trigger settings in SharePoint: Disable versioning or use a dedicated status column to avoid re-triggering.
- Flow action “Update item”: Always include a check to stop the flow from running on its own changes.
Why the SharePoint Item Modified Trigger Creates an Endless Loop
The Power Automate trigger “When an item is modified” fires every time a column value changes on a SharePoint list item. When your flow uses an action such as “Update item” to modify the same item, that update counts as a new modification. The trigger fires again, the flow runs again, and the update action runs again. This cycle repeats indefinitely until the flow runs out of runs or you stop it manually.
The root cause is that the flow does not differentiate between a modification made by a person and a modification made by itself. By default, Power Automate treats all changes equally. The trigger has no built-in filter to exclude changes made by the flow. You must add a condition to break the loop.
How the Loop Starts
A typical loop sequence looks like this:
- A user edits a list item. The trigger fires.
- The flow runs and updates a column on the same item.
- The update triggers the flow again because the item was modified.
- Step 2 and step 3 repeat until you stop the flow.
Common Scenarios That Cause Loops
Any flow that updates the item that triggered it can loop. Common examples include:
- Changing a status column after approval.
- Updating a calculated field with a timestamp.
- Setting a flag to indicate processing is complete.
Steps to Stop the Endless Trigger Loop
You have several methods to break the loop. The best approach depends on your flow design. Follow the steps below for each method.
Method 1: Add a Condition to Check the Modified By Field
- Open your flow in Power Automate
Go to make.powerautomate.com. Select My flows and click the flow that is looping. Click Edit. - Add a trigger condition
Click the trigger card When an item is modified. On the right panel, expand Advanced options. Scroll to Trigger Conditions. Click Add. - Enter the condition expression
Paste this expression into the condition box:@not(equals(triggerOutputs()?['body/Editor'], 'your-service-account-id'))
Replaceyour-service-account-idwith the object ID of the service account or user that runs the flow. To find the ID, run a test and inspect the Editor field output. This condition prevents the trigger from firing when the flow itself made the change. - Save and test
Click Save. Turn on the flow. Make a manual change to a list item. Verify the flow runs once and does not loop.
Method 2: Use a Dedicated Status Column
- Add a Yes/No column to the list
In SharePoint, open the list. Click Add column and choose Yes/No. Name it Processed. Set the default value to No. - Modify the trigger condition
In Power Automate, open the trigger card. Add a trigger condition that checks the Processed column equals No. Use this expression:@equals(triggerOutputs()?['body/Processed'], false) - Update the flow action
In the flow, after the main logic, add an Update item action. Set Processed to Yes. Because the trigger condition now requires Processed to be No, the update to Yes does not re-trigger the flow. - Save and test
Click Save. Turn on the flow. Edit an item. Confirm the flow runs once and stops.
Method 3: Turn Off Versioning for the Updated Column
- Go to list settings
In SharePoint, open the list. Click the gear icon and choose List settings. - Open versioning settings
Click Versioning settings. - Disable versioning
Under Content Approval, select No. Under Create a version each time you edit an item, select No. Click OK. Note: This stops the trigger from firing on version changes but does not prevent all loops. Use this method only when the flow updates a column that does not require version history.
If the Loop Still Occurs After the Main Fix
Flow still loops after adding a trigger condition
The trigger condition may not match the actual field name. Check the Editor field ID in the trigger outputs. In SharePoint, the field ID for the modified by field is not always Editor. It may be Author or a custom internal name. Use a compose action to output the full trigger body and inspect the field names.
Multiple flows on the same list
If you have more than one flow triggered by item modifications on the same list, one flow may update the item and trigger another flow. That second flow may update the item again and trigger the first flow. Review all flows on the list. Add the same trigger condition to every flow that updates the list item.
Concurrency settings cause overlapping runs
If your flow has concurrency enabled, multiple instances may run at the same time. An update from one instance can trigger another instance. Go to the flow settings. Under Concurrency control, set the degree of parallelism to 1. This forces the flow to process one trigger at a time.
Trigger Behavior: Standard Flow vs Automated Flow
| Item | Standard Trigger (When an item is modified) | Automated Flow with Trigger Condition |
|---|---|---|
| Fires on any column change | Yes | Yes, but filtered by condition |
| Fires on flow-made changes | Yes | No if condition excludes flow account |
| Requires manual stop on loop | Yes | No |
| Best for single-user updates | No | Yes |
The key difference is the ability to filter out changes made by the flow itself. Without a trigger condition, any modification including those from the flow restarts the trigger. With a condition that checks the Editor field or a dedicated status column, the flow ignores its own changes and runs only once per user edit.
To implement the most reliable solution, use a dedicated Yes/No status column combined with a trigger condition. This method works regardless of which user account runs the flow. Test the flow with a single item before enabling it on the entire list. Monitor the flow run history for the first few minutes to confirm the loop has stopped.