“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:
- The flow will trigger on each update, that’s a lot of useless flow runs.
- On the other side, you can use data from other sources. Using the trigger condition you can compare only data from the trigger itself.
- 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.
I have tried this option but it still triggers the flow
You have to change connection from update item control and send mail control. Set trigger mail address as connection .
Which solution did you try?
i tried
@not(equals(triggerOutputs()?[‘body/Editor/Email’],’SPconnectionaccount@company.com’))
with my account email of course instead SPconnectionaccount@company.com‘
and it triggers, what am i doing wrong?
Hello Kris,
you can try to create the trigger condition from scratch with the ‘Filter array’ action, maybe it’ll help.
Hi Tom
I have the same issue as Kris and even used the Filter array to generate the expression. The strange thing is that I have older items in the list, for which the flow is not running. As soon as I update an item from the list for the first time, it is included in the loop.
Thanks,
Benno
Hello Benno,
I just tried it on my environment an it works as expected. Try to debug your flow by adding 2x ‘Compose’ action after the trigger, store the ‘Modified By Email’ in one of them and the email address in the other. That way you can check if the values are really equal in the flow run history, and adjust the trigger condition if needed.
Thank you so much , your trick about debugging worked for me. Really appreciate Tom.
Stupid that this option is hidden in a background menu.
When you use a condition statement which does the same as the statement it will give these warnings all the time
Hello Tom,
Thank you for your explanation. But what’s the point if the flow won’t re-trigger for a file change or modified, for example, if this person remodifies the document (after getting the approver’s comment, for example) I won’t be informed about his next changes?
Is there any best way to do this?
Thank you and appreciated,
The name of the account that last modified the list item is not in the body, so the trigger condition is not working. Is there something I am missing?
Hello kpkp,
try using the ‘Filter array’ action to build the trigger condition, that should make it reliable: https://tomriha.com/a-simple-way-to-create-a-trigger-condition-in-power-automate/
Hello I have a flow which runs in
1. When an item is created or modified
2. Update item:- in this i’ve used expression “add(triggerBody()?[‘ID’],1000)” to add ID’s
3. Get items:- in this i’m filtering entries based on ID
4. Condition:- in this i’ve used expression “length(outputs(‘Get_items’)?[‘body/value’])” and then update item, create item
Basically the flow updates the item with ID’s and then copy’s the entry and pastes it into another list (which acts as a database to feed into power bi)
The flows in infinite loop an when there are more than 20 entries inthe list the performance slows down is there a way to stop this
Hello Harshad,
you have 2 updates in the flow, that’s 2 situations you must take care of to avoid the infinite trigger, that’s all I can tell you based on the description.
Hi Tom,
I too am getting an infinite loop when setting an item to a choice column value to “On Journey”, and it’s puzzling, because another time I’ve used this trigger condition method, it doesn’t keep looping. The trigger I’m using is “when an item is created or modified”.
@equals(triggerOutputs()?[‘body/field_54/Value’], ‘On Journey’)
Hello Steve,
if it’s just this trigger condition then it’ll trigger the flow with every following update as long as the choice value is “on Journey”, maybe you need more than 1 condition.