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.




Frequent Visitor

@normmsnpoweruse I created a "RunFlow" column, if the field is equal to "Yes" the flow sets the column to "No" and does the rest of the app logic inside of the true section of the conditional statement. When a user submits a powerapp form, the submit button patches into the list and changes the "RunFlow" column to "Yes"


It will run a second time, but since the flow doesn't update the item in the empty false section of the conditional statement, it wont trigger a third flow.


Annoying that I'm burning through twice my flow run limit, but I couldn't think of another workaround.


EDIT: looks like this is also the solution that @Audrie-MSFT linked to earlier in this thread:

Advocate IV

@normmsnpoweruse  - My solution was similar to @pcopeland . I'd have to burn up two flows.

Frequent Visitor

Unfortunately most of our flows go through at least 5 approval steps, which means


5x2=10 flow runs per item. 

4,500 monthly flow limit for Plan1/10 flow runs= 450 max items can be created a month..

Advocate II

I decided to post a solution which does not cause re-triggering, but it involves using XML and knowledge of the SharePoint API's.


You can read about over at


The challenge is that any update in SharePoint causes an event (webhook) to trigger, except what SharePoint calls a SystemUpdate. This API is not available in REST, but can be still be called via the "old" API endpoints using XML. So until the SP connectors support SystemUpdate, or something else is implemented in the backend, this is what you have to resort to 🙂



Thanks for posting your solution. It is just weird that MS is ignoring this important problem for more than a year now.

Frequent Visitor

Very interesting approach @Mikael_Svenson, if I have a flow that needs to update just a few fields I'll use your solution.

Advocate II

I have updated my post to reference John Liu's post ( - using another API which I couldn't get to work at first - as locale plays a part here. I also have a small update to his JSON payload.

Advocate V

I simply don't understand the solution:

"*The flow checks if the file is ready for review using a condition to check a field."

Of course I can make a check if a field has a value "yes" or "no". And if the field is "no" i can do nothing. I understand that, that's really no problem and easy.

But I dont't see or I dont' understand the solution, how sharepoint (and only sharepoint and flow, without powerapps) is able to get the difference if the flow makes a self triggering by edit the same item which triggered the flow. (In which case you want to prevent the modification in the 2nd run).

Or if it is a "real" modification of a person, which makes a real modification to the item in sharepoint by simply editing the item.

How do I control this custom "field" which controls the "condition" if the flow should run in "do nothing" or in "do the approval and self-modification really".

And how this custom "field" could be "No" on a run through, if it the flow is triggered by itself or "Yes" if triggered by a real modification of a real user in sharepoint?

I could do it ones of course. The modification of a user starts, I set the field to "next modification is valid" = "NO". So, the flow knows, that the next modification comes from self-triggering, after the approval.

But then I had to "clear" it and and have to set "next modification is valid" = YES in the "do nothing"-condition-branch.  I don't see that in the provided solution. 
(Also this solution would have big prolems, when 2 person edit the item in parallel, or simply when the same person edit the item twice in a row and not waiting for the first approval)

I don't see this "clearing" in the solution. So, I don't get the point of the linked solution. Can someone explain better how to use the solution to prevent (multiple) self-triggering?

It must solve it in this situation:

- No need of Powerapps.
- Creating and Editing of SP items in Sharepoint itself is the goal, without "multiple self-triggers"
- On every Create and Edit a SP item a Flow starts, which also starts an Approval!
- After Approval the flow changed the item which has triggered flow itself (Important: it change itself, and it change after Approval).
- Solution should be stable, even when someone edits an item in sharepoint twice without waiting the approval of the first modification. And also, when two persons edit an item and one person did not wait for the approval of the edit of the other person.

Can some one explain the solution of "Melissa Hubbard".
It looks very simple, but I don't get the point. 😞

Thanks a lot!


Advocate V

I am really in bad mood right now. I got personal feedback from Melissa, that her solution is only working one time. (First ceration or first modification). That's not the thing this flow-idea is about. We need a generell solution for self-triggering flows. And this small solution with one condition for "do the approval branch" or "do nothing" is not helping at that point.

Because the reset of solution to control the field which controls the conditions is missing. And here big problems begins. 


"Audrie-MSFT (Flow Staff)" was promising a solution months ago. We are still waiting.

@Audrie-MSFT : Still it would be nice to have a easy solution provided or get this top voted flow idea provided by MS.


The other solution of "Mikael_Svenson" could be working, but I think it's really complicated and a lot of work, when you have many fields in the item. And I am not sure if this solution will work forever. The solution reads more like using a glitch to overcome MS usage of flows like MS designed it.


Of course thanks to Mikael and Mellisa for their ideas.


But I look forward for a generell solution of MS. Or a better/simple workaround in actual flow possibilities.

HI @teqs ,


I think the easiest solution is to have a shadow list. In this shadow list you add a record when your flow is triggered with the ID of the item/document (and if you need it for multiple libraries then simply add the document library ID too).


Then at the end of the flow remove the item from the shadow list.


Beforee you add an item to this list check if it already exists and  if it does exist then exit out straight away. This means that the item in the list is like your disabling the event firing.