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 II

I'm surprised this hasn't been addressed yet...

@darogael - what, in your estimation is the best workaround for this issue (perhaps you could link to it?)? I'm struggling to find an acceptable method

New Member

Hi Mate,

Thanks a trillion mate!
It works like charm, saved a lot of energy & time.

I’m trying to get an Entitlement Collection running on a NetApp vFiler in 7-mode. The Resource Crawler works fine but the Entitlement Collector fails with the following error in the logfile:

Failed invoking API —> System.Net.WebException: The request was aborted Could not create SSL/TLS secure channel.


We have both ssl and tls enabled on the NetApp:

options tls.enable

tls.enable on


options ssl

ssl.enable on

ssl.v2.enable on

ssl.v3.enable on

SIQ Entitlement Collector fails on NetApp 7-mode with SSL error?

Anyways great write up, your efforts are much appreciated.


Kudo Kingpin

@Jeff_Thorpe Thanks!


I agree 100%... Everybody's work is a little different but it is not an exaggeration to say that nearly every Flow I want to create currently is affected in this issue in some way.

Frequent Visitor

Or maybe indicate on the sharepoint item that it was last modified by Flow, instead of the user name. Then it would be easy to have a condition to see if Flow was updating or user.

Frequent Visitor

I agree.

MS Flow needs to run a single instance of each worflow, by default - just like under WF2013.

Kudo Kingpin

I totally agree with this.  Today, the person creating the flow must set a flag so the flow will not perform the same logic twice if the trigger is Update Item in a SharePoint list.  Right now, the flow will fire twice.  There should be a way to add a setting in the trigger to fire once if the same item calls the trigger in less than x seconds - say 5 seconds for example...

Regular Visitor

Try taking a look at the trigger setting:

Concurrency Control
Limit number of concurrent runs of the Logic App, or leave it off to run as many as possible at the same time.

And pair it with what you are doing.  This will ensure that whatever changes may happen will not trigger the same flow again until its run is complete.  

You can also create and utilize a hidden int field with the value of: "ticks()".  The ticks function allows you to get the exact utctime in nanoseconds that you can query your next flow against.   While a bandaid, it should help alleviate some issues you are facing.

But yes, a run once would just be much nicer.

Frequent Visitor

I run into similar problems, possibly solvable by logic in the flow. However this is not optimal and may force some customers to be forced to upgrade plans to allow more flows per month. 

Frequent Visitor

Does anyone have any suggestions on this? In SharePoint 2010 workflows this worked without the workflow retriggering. This is a real drawback to adopting O365 as a business platform. The initial post asking for help on this was created 6 months ago. Can we get any movement on this? Is there another thread that addresses this? I haven't found one that is satisfactory.

Regular Visitor

I just ran into this same problem and I am just stunned that the MS Flow tool is missing this key component.  It really is NOT ready for primetime.. as the most basic operations seem to not work.


1) being able to determine if a specific field has changed

2) updating the same item in a sharepoint list and NOT re-triggering the workflow...