How to avoid infinite trigger loop in Power Automate

“I’d like it to update a SharePoint item in Power Automate but I am getting a warning “Actions in this flow may result in an infinite trigger loop”.”

“This exact workflow design had no issues running in SharePoint Designer. Now all of a sudden, the same steps/logic in Power Automate result in this inadvertent looping.”

“Actions in this flow may result in an infinite trigger loop. Please ensure you add appropriate conditional checks to prevent this flow from triggering itself.”

---

In the past you maybe used 2010 or 2013 workflows (or Nintex workflow, which is using the 2013 workflow engine), and it was not possible to start multiple instances of a single flow on a single SharePoint item. But now, with the standalone Power Automate flows, such situations happen. Especially when you’re using trigger on ‘When an item is created or modified’ and you do an ‘update’ inside the flow. The Power Automate flow will end in an infinite trigger loop because of that update. What “conditional checks” should you add to avoid it?

Trigger condition

The best and most efficient way is to add a trigger condition inside the trigger settings. The trigger condition blocks the flow from starting if the condition is not ‘true’. You can not only avoid the infinite trigger loop with all the updates, but also save flow runs. No more empty flow runs.

The limitation is that you can’t use any ‘dynamic content’ and you need to define the condition in the old, type-it-all way (using column internal names).

Update: you can use the ‘Filter array’ action to create the trigger condition for you.

Trigger condition on ‘Modified By’ column

My favourite is to disable the flow run if the last update was done by a specific account (using its email address). It could be a service account, your account or somebody else’s account, whose connection the flow is using. If the item was updated by this account = it was done by the flow = don’t start it again. If it was modified by another account, start the flow.

@not(equals(triggerOutputs()?['body/Editor/Email'],'SPconnectionaccount@company.com'))

The limitation is that the account won’t be able to start the flow, ever. If you’re also user of the flow and you don’t have any other account, you can’t use this condition.

Trigger condition + version history check

One more approach I thought of (much) later, using trigger condition in combination with version history. I consider it the second best solution after having a separate account.

Trigger condition on two (or more) columns

If you can’t use the trigger condition based on the ‘Modified By’ column, maybe there’s a different column you could use. Some column updated by users. You can create a copy of that column, let’s call them ‘Column’ and ‘Column_copy’. Each update in the flow will update the ‘Column_copy’ = ‘Column’ to keep them synchronized. That means, the only situation when the columns will have different values is when it was updated by a user = run the flow.

@not(equals(triggerOutputs()?['body/Column'],triggerOutputs()?['body/Column_copy']))

With a coding knowledge you can build really complex conditions, using data from existing columns or fixed values. While you can add multiple trigger conditions, the operator is always AND. For OR operator you’ll need to put all the conditions into a single line. In the example below you can see the 2 conditions above combined with OR operator.

@or(equals(triggerOutputs()?['body/Editor/Email'],'SPconnectionaccount@company.com'),not(equals(triggerOutputs()?['body/Column'],triggerOutputs()?['body/Column_copy'])))

Update: you don’t need to stop with checking one column, you can check multiple columns and trigger the flow only if one of them is updated.

Condition action

Another option is to add a condition before each update. Check, if the flow should do an update, or if a previous instance of the flow already did it. For example, you need to update item status to ‘In approval’. You should add a condition before the update and do it only if current status is not ‘In approval’.

This approach is similar to the trigger conditions, with a few differences. Using the ‘Condition’ action:

1. The flow will trigger on each update, that’s a lot of useless flow runs.
2. On the other side, you can use data from other sources. Using the trigger condition you can compare only data from the trigger itself.
3. You can use complex conditions without the coding knowledge.

Summary

I find the possibility of updating loops one of the most annoying things when using Power Automate. It’s easy to solve if you’ve got a separate account just for Power Automate or if you’re developing solutions for somebody else.

But if the flow is for your personal use, the workarounds get more complex. You need to manage ALL update actions in the flow, either by building complex trigger conditions or by additional ‘Condition’ actions. I still consider the trigger conditions a better solution, but I can understand it you decide to go with the ‘Conditions’ for its simplicity.

---

Do you struggle with the various expressions, conditions, filters, or HTTP requests available in Power Automate?

I send one email per week with a summary of the new solutions, designed to help even non IT people to automate some of their repetitive tasks.

All subscribers have also access to resources like a SharePoint Filter Query cheat sheet or Date expressions cheat sheet.

First Name

Email address

Zero spam, unsubscribe anytime.

Leave this field empty if you’re human: