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.




Advocate IV

I've gotten around this issue by using a service account to make updates to the list.


My flow checks who modified the list last, and if it's the service account, it stops.


But like someone mentionned in the earlier comments, seems a little hacky and it isn't perfect.

Advocate IV

 Please be a lad and give a vote to my idea, to increase the approval timeout (or just general flow timeout) to MORE THAN 30 DAYS!!!!



I'm at 155 votes, more is better.



Kudo Kingpin

This issue, and the companion issue that causes all queued Flow runs to unexpectedly execute the moment a Flow is turned back on after having been turned off (in some cases thousands of queued runs) makes me avoid using Flow for any complex business process automation. This is really too bad as I certainly see the powerful capabilities that exist.


A typical account of a user coming to a nightmarish realization of Flow's 'queued run feature' can be read here


While it is clear that there are hacky workarounds to mitigate the potentially career-ending implications of both of these issues, I suspect some people are uncomfortable relying on these carefully constructed 'house of cards' type solutions that are essentially laying a trap for the future when a change to the Flow is made, the work-around fails, and thousands of emails, approvals, etc. are initiated. These is more likely to occur later, when the details of this type of work-around fade in the memory of those who implemented them or are unfamiliar to new folks working on the Flow.


Constructing dozens of Flows, all dependant on delicate work-arounds to prevent publicly embarrassing episodes related to self-retriggering and massive, unexpected execution of queued Flows is not an attractive proposition for me (even though I do know how to do it).



New Member

I am just getting into flow with SharePoint as we start working with modern lists and libraries. I rewrote a designer workflow to work in flow, and found this to be a HUGE issue. What is disappointing is the lack of response on the topic. Is it even being considered? We compare a current and previous status to see if the logic needs to be run and then update the previous at the end to match the current. So of course every flow is triggered twice though the logic stops it from running completely. Designer didn't do this in 2010 or 2013. If MS wants to keep pushing these newer tools, they should look at what we had before and make sure basics can be delivered. 

Kudo Commander

This is HUGE!  Having this feature will make life in FLOW much, much easier and may even up open doors previously unavailable!!!

Regular Visitor

Might I suggest an alternative: allow flows to be marked as "no reentry".

Often times, I have several flows acting upon updates in SP items that may result in different updates of the field itself. I typically don't mind one flow to trigger the other, but I don't want "reentry" (the flow retriggering itself).

This may not be obvious to implement...


Another alternative is to have the "Update Item" not do anything if there is actually nothing to update (and/or not trigger flows on SP items if the update "didn't actually do anything). In fact, this may be the best solution and would stop all endless loops. Important: you'll have to define "nothing to update" in the case of floating point values (e.g. if the difference is no bigger that e-5 or something). This is probably a good idea, as it is what I'm manually implementing at this time in all my flows where I need to prevent reentry, and it's working. This is perfactly feasible too.

Power Automate
Status changed to: Under Review

Thank you for your patience as we consider opportunities related to this excellent idea. We will keep you updated as we solidify options.



Kudo Collector

Hello Flow Team,


please make this feature happen! It is needed. There are many ideas for workarounds for this "self-triggering"-problem, but all have downsides and have possibilities for bugs in complex flows and on higher frequency. 


It doesn't make sense, that a flow with a "When an item is created or modified"-Trigger triggers itself when changing itself.


For me it seems, also the content approval on a "When an item is created or modified"-Triggered-Flow triggers itself, when the flow goal is to change the approval status of the item which triggered the flow.


You could add Options to Content-Approval-Nodes and to Edit-Item-Nodes to make selectable per option to switch off (or on) that this change triggers a new "When an item is created or modified" by itself. Or simply switch this kind of self-triggering off be default. In most cases, this kind of self-triggering don't make sense.


@NickSabbe @Audrie-MSFT 

Also NickSabbe and other people in teh comments had good ideas.


Thanks a lot!

Power Automate

@Jeff_Thorpe Thank you for this idea post. In the meantime, while we are determining feasibility, I am putting together a few work around videos. Would you like to work with me on this?


Thank you again,


Super User

@Audrie-MSFT , thanks for reaching out. It would be greate to work with you on this issue. I believe you have my email but if not just DM here and I'll send it to you.