cancel
Showing results for 
Search instead for 
Did you mean: 

Disable Event Firing when Flow updates a SharePoint list item

Add a feature that will allow flow to disable event firing when updating a SharePoint list item, so that the Flow doesn't get stuck in a loop. Currently if I create a flow with a SharePoint list trigger when item is created or modified and have the Flow update a field in the item the loop gets stuck in a loop. One workaround is to add logic to check if the field(s) still need to be updated and if not then don't update the item but even in that case the flow will be triggered twice. It just makes sense to have an option that will allow Flow to update an item without triggering an event that will cause the same Flow or another Flow to run against the item again.

Status: Declined

Hi all,

 

After thoroughly reviewing this idea, we have decided not to proceed with this idea for a couple of reasons.

  • SharePoint events are no longer event receiver based and are performed using webhooks or polling where applicable
  • Other Office 365 applications and internal systems like auditing may and will rely on such changes like updates to items, files and other entities in SharePoint

However, that said, we understand the crux of the issue which is to help avoid loops. We will work with the flow team to come up with a generic model/pattern that applies across data source/connections for similar scenarios.

 

Thanks all for your input and please submit/vote your ideas as we are actively monitoring the ideas forum.

 

Thanks,

Chaks

Comments
Level: Power Up

And how did you prevent the integrated "sign-off" flow for a document from looping? It seems this flow can update the column without triggering the flow again.

DaV
Level: Powered On

@Chakkaradeep 

Kindly say when will the solution for "stop self triggering" or avoiding the loop (or whatever name you like) be present in production. 

Thanks

David

Level 10

I create a account for these types of flows ( all flows really ) 

and then put in the following conditional start:

 

@not(equals(triggerBody()?['Editor']?['Email'],'svc-SPAppsFlowAdmin@company.com’))

 

as long as they are not a real user but a service account then they wont interact with the items directly requiring the flow to start. This way you have the best of both worlds, as there may be some reasons to start a loop to simplify your flow design based on conditions for example to start the process again. i.e. if a approval column is set to ReApprove to go back thorugh a process or whatever

 

Level: Powered On

Still nothing on this? We just moved to away from 2010 and I had to start using flows. I guess I can just pile this onto why we are looking for alternative solutions. It seems like a lot of "ideas" that are actually poor design or bugs on very simple topics are not addressed and when they are, it is a vague and untimely reply.

Level: Powered On

Had to revert back to using SP Designer 2013 to accomplish the task.  I started creating a new simple Flow with the intent of updating a column in sharepoint every time it is edited. Then remembered that type of scenario causes a loop. Pretty sad.