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.




Level: Powered On

I think what @Chakkaradeep means is that Flow/LogicApps need to add a concept of ignoring triggered items on certain conditions in a general way. Any source having a trigger would fire that trigger when you update the item, which for the source system is good for auditing scenarios.


For SharePoint in particular you can workaround by using SystemUpdate as I've blogged, but this is very SP specific, and by using SystemUpdate you sort of miss a version trace of the update as well - which might not be what you want.


So it's a simple scenario, which is harder to solve in a general technical way.

Level: Powered On

@Mikael_Svenson : I think you just want to help, but sorry, I am still not satisfied. 

- This is a top10 voted idea. Top 7 actual!

- on page 13 and 14 you see how easily you run into this problem

- And we get no solution for it! The idea is declined. 😞


As I said before, the "workaround by using SystemUpdate" is very kind of you, and you must be very SP skilled to come to such an idea. But for me it reads more like a glitch like a supported solution. Perhaps it is not working anymore on the next update. Also a bit complicated. And also we have Versioning on this SP Lists, so we need "version trace".


I hope @Chakkaradeep and the Flow devs will come up with a real solution.


Flow Staff

@teqs I would separate the two things:

1. Fixing the issue where updating an item triggers the same flow

2. Ability to disable event firing when updating a SharePoint list


Problem #1 is not unique to SharePoint actions. This should be a separate idea and it would be great if you can start a new idea as it would help us collectively come up with a solution if any to manage this particular problem.


Problem #2 is what this idea is about. This is specific to SharePoint. And I outlined the reasons why we had to decline this idea.


I hope that helps.




Level 8

What would really help is if the "problems" you accurately described were addressed in a way that would make them not problems for the thousands of users who wish to build simple workflows (ones that used to take a few minutes to create using previous tools). Soliciting ideas from customers, then spending time and effort arguing why you’re declining the customer's top-voted ideas, is not particularly helpful to the customer. Nor is suggesting the customer must now submit another new idea, particularly after the original one was dismissed with a “declined” banner across the “idea” (which is really a “problem” as you even described it as, not an “idea”).


It is understood that there is a process around evaluating and adding new features, and that features must be implemented in a logical fashion, however it is also understood that fixing this and providing your customers a way to do what they need to do is currently well within your technical capabilities and that we must do without for the sake of ideological purity.


I can’t even make the non-technical leaders I work with believe that this simple thing cannot be properly accommodated by Flow. Luckily I have 16 pages of customer feedback I can provide them to demonstrate.

Level: Powered On

"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."


That's a cop out, and quite frankly seems a lazy way of addressing an issue that has 16 pages worth of comments.


This suggestion has a large amount of votes and needs to be addressed.


Once again, Flow, as a business tool, is not readily supporting BUSINESS scenarios, and at the same time, causing headaches with quotas.  That is grossly unfair on two fronts.


Someone has come up with a workaround solution (and a big thankyou to @Mikael_Svenson !)  Maybe Microsoft could do the same by taking their lead and packaging/adding a similar actions (i.e. an action that supports ValidateUpdateListItem with the ability to set bNewDocumentUpdate) to the already badly lacking list of SharePoint actions in Flow, instead of throwing their hands up in the air and saying "sorry, it's too hard".