Showing results for 
Search instead for 
Did you mean: 

Turning off Flow and turning back on still create new instances of Flow


Currently we are working on a bunch of flow automation logic with SharePoint connectors. The issue we have is that flow queues SharePoint list item changes even when the flow is turned off. Since we have many SharePoint metadata that are updated in bulk while testing, there are many flows that are triggered on error data after turned on. We don't want this to happen. When we turn off the flow, we want it to not run later.

When we turn off the flow, we want it to not run later.

Status: Under Review

Thank you for the suggestion. As is covered in the comments this is not a bug but an important feature to avoid data loss -- this allows you to temporarily disable a flow, make corrections, and then enable the flow, running it over all of the events that happened in the interim. Without this functionality all of those business critical events would be lost.


That being said, there may be scenarios where you want to explicitly discard your business data -- to support that case we'll look at adding an option to delete the trigger data so you can start again from scratch.

Regular Visitor

Discovered this thread because I too got burned by this and was looking for an explanation. I had to do a similar thing to @RachelRig to 'short circuit' every run to a cancelling termination, the revert to how things should be.


As mentioned elsewhere, it would be good to get a prompt when re-enabling a stopped (paused!) flow that asks: 'Process queued trigger events?', or have a page section adjacent to Runs called Queued and allowing selection of what to retain/delete.

Frequent Visitor

The problem with the "short circuit" approach is that it can take quite a while for the queued up workflows to run - I think there's a limit on how many flows it will let you run in a period of time.  In my case, I had ~300 items updated.  I turned the flow back on at about 6:45pm, the next morning it showed those queued flows were continuing to start until about 12:45am, ie approx 6 hours.  Which means that the "short circuit" would have needed to remain active for at least that long (longer if there had been a larger number of items updated).  This has the potential to interfere with legitimate updates done by users during that period of time that it's still churning through the queued updates.  Obviously you can try to work around this with the right conditions in your short circuit IF statement (e.g. terminate if the modified by user is whatever credentials the update script ran under), but there's still the risk that it will send out notifications you don't want or, alternately, not send out notifications that you do want (especially if the user running the script is also a regular user of the list).


It just seems a very convoluted solution when a simple one would be to have 3 states for the Flow - On (normal behaviour), Suspended/Paused (not running but queuing any run for when it gets turned back on) and Off (not running and will not fire for any updates made while it's set to Off).

Regular Visitor

Obviously YMMV; in my case it was more practical to use a blunt instrument like the short circuit than spend time dealing with handling the various possible trigger combinations.


Sure, I could build all my Flows from now on to accommodate the platform's behaviour, but I'd rather not, thanks 🙂

Frequent Visitor

My solution for this is to turn off the flow, make your changes in your Data Resource like a Sharepoint List. Then export this flow, delete the Flow and reimport it again. Then it wouldn´t run the queue.

Advocate II

Hi @Andi690 Yes this is exactly how I manage the situation although it is a Faff and you have to remember to do it. 

Regular Visitor

Thanks for the many suggestions for work around. This definitely needs to be addressed quickly. I was about to launch something and noticed the strange behavior. Thankfully I didn't go ahead....

Resolver II

Experiencing this right now as I type; sent 4000+ emails after importing historical data from SP On-Prem to SPO after migration. Not a great experience!

Advocate II

A workaround that I just used was to add an "impossible trigger condition" to the Flow trigger.

In my case I have a flow that is triggered when a SP item is deleted and when I had to delete 1500 corrupted items I didn't want the flow to run 1500 times.

So I added this "Trigger condition": "@equals(triggerBody()?['Title'],'fdsasfdggfqrgrhthhyt')"

where "fdsasfdggfqrgrhthhyt" is a dummy Title that does not exist.

This way I could delete my items, wait for 30 min or so (just to be sure) and the remove the condition to have the flow working again.


2020-09-16 14_16_49-Edit your flow _ Power Automate.png

New Member

Any updates on this? Much needed.




New Member

Any updates on this? Much needed.