I know there am some topics about this. But I never saw an answer from Microsoft so
if a flow triggers on update item and you update a SharePoint item in your flow causes flow to fire again and again.
Sry Microsoft but this is a huge bug. Is this in on any Backlog from Microsoft to be fixed in the future or should I tell my customers the old SharePoint Designer workflows are the better solution to work with in SharePoint?
You know my guess is that Microsoft is not EVER going to fix this issue because its hard...unlike Sharepoint designer workflows that get triggered by event receivers that are disabled while a sharepoint designer workflow is running preventing runaway workflows... they may simply have no way to do this with Flow which apparently uses some other triggering mechanism which they can not turn off while the Flow is running.
So the only workaound to make a FLow that updates an item that triggers it is to use an hidden flag field in addition to the condition clause -- the flag field is set to Yes by default when the item is created then then you add that to the condition clause (Flag Field equals Yes (in addition to whatever user changes cause the Flow to run) and when you update the item part of that update is to set the hidden Flag field to No. Then there will be no looping and the Flow will only run once -- of course if you want the flow to run multiple times based on a user change to a field (then you have to reset the condition in the Update action in order to prevent runaway flows)
I agree with @SPMP's thought almost. If you use the "When an item is created or modified" trigger as the trigger of your flow and add a "Update item" action within the flow, when you update an item in your SharePoint list, the flow would be in a infinite loop.
There is no direct way to fix this issue in Microsoft Flow currently, if you would like this feature to be improved in Microsoft Flow, please submit an idea to Flow Ideas Forum:
In addition, you could consider take a try with the way @SPMP mentioned as an alternative way. You could consider add a custom Choice type column called UpdateFromFlow within your SharePoint list, the default value of this column set to No. Add a Condition under the "When an item is created or modified" trigger within your flow, check if the UpdateFromFlow column is equal to No. Within your "Update item" action, set UpdateFromFlow field to Yes.
Within the Condition box (under the "When an item is created or modified" trigger), if the UpdateFromFlow column is equal to No, it indicates that the flow is fired based on an item is created or modified (UpdateFromFlow column is not set to Yes) in your SharePoint list, if the UpdateFromFlow column is equal to Yes, it indicates that the flow is fired based on the "Update item" action within your flow.
I too encountered the "feature" where a "When an item is created or modified" Flow would loop on itself when the Flow updated one or more items in the trigger list.
I have been able to work around the issue, and thought it might be useful to share some notes on how. If it would be beneficial to people I can expand in more detail.
I have added a Condition in the Flow directly after the trigger to check whether the item was last modified by the Connection account used by the Flow - if it was then I terminate the Flow with a dead-end.
Flows require a Connection to SharePoint - by and large I use my own 365 account to create the Connection. In doing so, when the Flow updates an item the modified by email is the same as if I had edited the item using the interface, using a SharePoint form - there is no distinction between automated ("Flow") and user action.
In production I will use a system account, however for development and playtime I used the following approach. I shared my Flow with a colleague. They were able to take each SharePoint interaction step in the flow and using the settings for the step tell it to use that colleague's Connection. When they save the shared Flow (Team Flow) their Connection is also shared with me. Therefore I can run the Flow as them (or me), and they will show as the last modified user email address, and I can use my Condition to quickly direct them to a dead end.
It is not a perfect solution, but it works for my purposes. The "Created or Modified" Flow does not run if the Flow is using a specific known Connection email address. It only runs in response to an action by a user - I think this will kill the loop?
There is another consideration with the trigger for me: there are certain things I want to achieve only when an item has been created. To support this I do not use the "When an item is Created" trigger as that duplicates with the “When an item is Created or Modified” – they both fire. Instead I have a hidden number column in my list item called "isNew" and set to 1 (true) by default. So, the first time my CoM trigger fires the isNew ‘variable’ is true and the logic for a newly created item is applied and isNew is set to 0 (false). The second and subsequent times the trigger is fired isNew will be false and the newly created item logic is skipped.
Have Flow update an item 'status' without looping the loop: I was desolate for days trying to figure a solution to updating a hidden status column in response to a user action but not a Flow action - the above differentiation of the Connection email address is a solution that might work for some situations. An alternative that I used (and can explain in more detail) is to create a [Statuses] list that holds the variable [Status] and the ID of the item in the list that you wish to change. It is a relationship created when an item isNew and the status in the list can be ammended without triggering the 'parent list' CoM.
I hope this is of some use. I know I did a lot of Googleslapping and pacing about to find an answer that worked for me. As mentioned, if it would be of use I can expand on aspects of the above.
I heard of one person fixing this issue by using a service account. What I don't understand is where in flow would you tag it as a service account. I know I use to do this for an on-prem sharepoint instance, but I have not seen this for Flow.
I have a resolution for this. Essentially you will want to add a condition.
In my case, it is based on the time of last modified+2 minutes (You can set it to whatever time interval you want, however I wanted to get enough time for the flows to run).
What happens is if the item modified time is greater than now time +2 minutes, it will run the update item. If it is les than 2 minutes it will terminate the flow, thus ending the loopback. While this isn't an ideal solution, it is a great work around, given the circumstances.
If you like this work around, please upvote it.
Any new solutions to this? I have used 2 accounts to get this to work, one to run the flow and the 2nd to update the item. Then i can use a condition to check for who last modified the item, and if not the svc account it will run but stop if it is that account. Some what of a pain, especially with SSO in most browsers.
Join digitally, March 2–4, 2021 to explore new tech that's ready to implement. Experience the keynote in mixed reality through AltspaceVR!
Many congratulations to the Season 1 2021 Flownaut Crew!
Check out our new profile badges recognizing authored solutions!
Check out the community blog page where you can find valuable learning material from community and product team members!