SharePoint When an Item Is Modified Trigger Loops Forever: What Site Owners Should Check
🔍 WiseChecker

SharePoint When an Item Is Modified Trigger Loops Forever: What Site Owners Should Check

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.

ADVERTISEMENT

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:

  1. A user edits a list item. The trigger fires.
  2. The flow runs and updates a column on the same item.
  3. The update triggers the flow again because the item was modified.
  4. 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

  1. Open your flow in Power Automate
    Go to make.powerautomate.com. Select My flows and click the flow that is looping. Click Edit.
  2. 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.
  3. Enter the condition expression
    Paste this expression into the condition box:
    @not(equals(triggerOutputs()?['body/Editor'], 'your-service-account-id'))
    Replace your-service-account-id with 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.
  4. 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

  1. 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.
  2. 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)
  3. 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.
  4. 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

  1. Go to list settings
    In SharePoint, open the list. Click the gear icon and choose List settings.
  2. Open versioning settings
    Click Versioning settings.
  3. 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.

ADVERTISEMENT

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.

ADVERTISEMENT