Power Automate flow keeps running itself over and over

Short answer: the SharePoint trigger "When an item is created or modified" fires on every change to an item, including the change your own Update item action makes, so the flow starts itself again. To stop it, add a trigger condition so the flow starts only when Status equals the value you act on, and set Status to a different value in the update. The exact condition in Step 3 is our advice, not a Microsoft rule.

What a loop looks like

You build a flow for a request list. When a person sets Status to Approved, the flow should do some work and then mark the item as done. It runs, and it runs again. And again. The run history fills up with runs for one item. You may see a warning about an infinite loop when you save, or you may not notice until the run list is long.

Microsoft's page on trigger conditions describes this trigger as one that "fires for every change to SharePoint items" and gives the case where you only want the flow to start when "the status is marked as Approved". A Microsoft Q&A answer to a person who got an infinite loop warning on this kind of flow also suggested a trigger condition. That thread does not show a confirmed fix, so the page you are reading rests on the Microsoft page, not on the thread.

Why it happens

Microsoft's SharePoint connector page says the trigger "Triggers the flow when you create an item, and each time you modify it in a SharePoint list." Microsoft's page on trigger conditions says: "This trigger fires for every change to SharePoint items."

Put those two facts together:

A person changes the item. The trigger starts the flow.
The flow has an Update item action on the same item.
That update is a change. The trigger starts the flow again.
The second run updates the item. Go back to step 3.

Microsoft's pages do not describe a loop by name or give a limit for how long it can go on. The steps above follow from the two quotes. Check them on your own list by looking at the run history.

Signs this is your problem

Several runs for one item, close together in time.
The number of runs is far higher than the number of items.
The flow has an Update item action that points at the same list that starts it.
The item shows a new "Modified" time over and over with no person editing it.

Step 1. Stop the loop now

Do this first so the runs stop piling up.

Open https://make.powerautomate.com and select My flows. Exact names may differ in your version.
Select the flow, then choose Turn off.
Open the run history and look at the newest runs. Note which item they belong to.
Fix the item if the flow left it in a bad state, for example a wrong status.

You can now fix the cause with the flow turned off.

Step 2. Set up a status column that moves one way

A loop stops when the flow changes the item to a state that the trigger ignores. For that you need a Status column.

Add a Choice column called Status. Use number prefixes:

1 New
2 Approved
3 Processed

Our advice, not a Microsoft rule: the number prefix makes the choices easy to tell apart in your trigger condition.

Every list also has a Title column. It is required by default. Rename it to something useful, such as "Request name", or turn off Require in the column settings. This matters for Step 4, because the Update item action may ask for it.

The idea: a person sets Status to 2 Approved. The flow does its work and sets Status to 3 Processed. The flow should act only on 2 Approved. Once the item is 3 Processed, a new run has nothing to do.

Step 3. Add a trigger condition

A trigger condition checks the item before the flow starts. Microsoft says: "If the trigger condition isn't met, the flow isn't triggered, and no run history is logged." Microsoft also says that when you filter inside the flow instead, "the flow still runs and the calls are counted as an API request." So a Condition action inside the flow does not stop the loop. It only decides what happens after the run has started.

Microsoft's help page for trigger conditions is linked at the end. The steps are:

Edit the flow and select the trigger.
Open Settings.
Next to Trigger conditions, choose Add.
Type the expression.

Microsoft says: "Every trigger condition must start with the @ symbol."

One way to start, for a Choice column named Status:

@equals(triggerOutputs()?['body/Status/Value'], '2 Approved')

Ready to copy for a Choice column named Status where the value to act on is 2 Approved: paste the line above into the trigger condition box, then change Status and 2 Approved to your own column and choice. Then the update action sets Status to 3 Processed, which the condition does not match, so the next run is skipped.

The text inside the quotes must match your choice exactly, including the number and the space. The column name in the expression is the internal name of the column. If you created the column with a space in the name, the internal name may look different, such as Request_x0020_Status. To see the exact name, open a past run and look at the trigger's outputs. Exact names may differ in your list.

The Microsoft Q&A answer used a different style. It blocked the finished states instead, with a condition that says to run unless the status is already Approved or Rejected. Both styles can work. I prefer to allow one state, because it is easier to read and a new status added later does not start the flow by accident. That preference is our advice, not a Microsoft rule.

Step 4. Update the item in one place only

Now check the flow itself.

Find every Update item action that points at the same list as the trigger.
Keep one. Set Status to 3 Processed in that action.
If the action shows Title as a required field, fill it with the Title from the trigger. Title is required by default, so Update item may ask for it. If you turned off Require, it may not.
Do not use the Update item action to write notes, dates or counters that change on every run. Each change starts the trigger again. If the new status is not the one in your trigger condition, the run is skipped. If you write other columns while Status stays at 2 Approved, the condition is still true and the loop continues.

If you must write several columns, write them all in one Update item action together with the status change.

Step 5. Test with one item

Turn the flow on.
Create one test item. Leave Status at 1 New. Nothing should run.
Change Status to 2 Approved.
Wait a few minutes. The trigger checks on a schedule, so the run may not start right away.
Open the run history. You should see one run, and the item should show 3 Processed.

Microsoft's troubleshooting page describes how to spot skipped checks: "A skipped check means the trigger condition wasn't met, and the flow wasn't initiated." Open the 28-day run history and select All runs to look for them.

Other ways to break the loop

Use a different list for the output. If the flow writes results to a second list, it never changes the list that starts it.
Use a Yes/No column. Add a column such as Processed and set its default value to No. Put it in the trigger condition and set it to Yes at the end. Our guide "Power Automate sends the same email two or three times" shows this pattern for duplicate emails, so I do not repeat it here.
Use "Get changes for an item or a file (properties only)". Microsoft says this action "Gets all the columns or file properties changed since and until a specified time interval." To use it, Microsoft says to use the trigger "When an item or a file is modified" and to use the "Trigger Window Start Token" and "Trigger Window End Token" outputs from that trigger to infer what columns changed since the last time the flow checked. Microsoft also says: "The list or library should have versioning configured in order to infer what columns or properties got modified since last change." So turn on versioning for the list first. Microsoft's page does not call this a loop fix. Our advice, not a Microsoft rule: use it to check which columns changed, and let the flow act only when the column you care about is one of them. Test it on one item before you rely on it.

What to avoid

Do not add a Condition action inside the flow and call it fixed. The flow still runs and still counts as a request.
Do not use a Delay action to slow the loop. It spaces the runs out. It does not end them.
Do not leave the flow on while you test. A loop can run several times before you notice.
Do not copy an expression into your flow without checking the choice text and column name against your own list.
Do not write to the same item from two different flows. They can start each other.
Do not use a status name that changes. If you rename a choice later, update the trigger condition too.

When to get help

You can build all of this yourself in Microsoft 365. If you would rather have it built and tested for your team, I do that. A tracker like this is a fixed price: $5,000 for one, built in 2 weeks. See "What a SharePoint tracker costs to build". Bring one example of the problem to a free call.

Tell me what's still manual

I am Al Davies. I run 250 High Street LLC and build SharePoint trackers and Power Automate flows for operations teams. I work remotely. The first call is free, and I will not try to sell you anything.

See trackers I built: Tools I built

FAQ

Why does my Power Automate flow keep running itself in an infinite loop?

The trigger "When an item is created or modified" fires on every change to the item, and the change made by your own Update item action counts. Add a trigger condition so the flow starts only for the status you want it to act on.

How do I avoid an infinite trigger loop in Power Automate?

Add a trigger condition on the trigger's Settings so the flow starts only for one status, and have the Update item action set a different status. Microsoft says that if the condition is not met, the flow is not triggered and no run history is logged.

Will a Condition action inside the flow stop the loop?

No. Microsoft says that filtering inside the flow means "the flow still runs." Use a trigger condition in the trigger settings instead.

What trigger condition stops an Update item loop?

Our advice, not a Microsoft rule: a line such as the Status example in Step 3 that starts only for one status value, with the update moving the item to a different value. Every trigger condition must start with the @ symbol.

How do I know the trigger condition is working?

Change an item to a status that should be skipped. No new run should appear. Microsoft says a skipped check means the condition was not met and the flow was not started. You can find these in the 28-day run history under All runs.