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.




Kudo Collector

@Chakkaradeep wrote:

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






I don't get the point. Yes, the topic sais "Disable Event Firing when Flow updates a SharePoint list item", but you could simply edit the title, when you think it is wrong. The topic content of the idea-creator itself is about

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


So the reason is, to not trigger the same flow which triggered a modification of the item which list has the same flow with a modification trigger assigned. In short .... "Stop self triggering" or better "make a optional-solution in the flow "create or modifictaion"-connector (or in somehwere else) to make stop stop re-triggering per option possible!"

--> To have no loops. To have not re-triggering flows even twice.

I think the topic is all about this!

Detailed real world explanations of the problem on Page 13/14.


So for me, your point #1 is a big part of this flow-idea. So no new idea with need of new collecting hundreds of votes are needed, because you have already this top voted idea which has to be worked on.

As you see in detail, when you not only read the topic title, but read the content of the idea creator. He sais also wrote: ;

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

That's exactly the problem. Of course you don't have to "Disable Event Firing" in general, find your own solution. On this 16 pages long topic also people have suggested already some ideas.

Already in the creator content.


Some additions you find over the pages....


Page2: by Mikael_Svenson

"When triggering on a SharePoint list/lib for modifed items it would be nice to be able to update the triggered item in the Flow without the Flow re-triggering on the update. Much like a system-update."

Page3: by kortvez

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

This is also a good idea by kortvez. So user could build very small workaround, by simply check if the modification of the item was done by the user itself, or if the item was changed by a flow which was triggered by the user.

Actually, we have no chance for this, because there is no field in the "create or update a list item" which has content about if the flow triggers by a "direct user modification" or "by a user who was triggering a flow, where the triggered flow makes the modification".

For example, you could make new informations available about the flow name (better unique flow ID) which triggered the item modification. You could make this information available in the "create or modify list item"-connector.


Page 4 by rbrosius

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

And much more… all of us addressed your problem out of your point #1. No new flow idea is needed, better work on this already top voted topic!


@PhilD  and @tism: I totally agree.

Power Automate

@teqsUnfortunately it creates confusion and ambiguity for users reading this idea to interpret into many variations. If the idea owner can change the title and description to fit the needs, then it is all good. However, this tool, in doing updates to the title and description will consider that as a new idea and will lose all the votes. The specific feedback around list/lib triggers you quoted is already looked into by this idea (which has higher votes and counting than this original idea) and we are hoping to address them one by one.


I will reiterate that this idea is declined only for SharePoint specific requirement that the original idea owner requested for. Declining this idea in no way declines the generic handling of such use cases in the Flow platform. We request, in those cases, to help us by creating an idea specific to that so its clear for users what the request is for. 





Kudo Collector

That's ridiculous. 


So, a bunch of people highlight, in many ways, a specific issue; i.e. if you update a SharePoint item during a flow that is triggered by the creation/modification of that same item, then the same flow gets triggered again.  But... because no-one posted the correct idea specific to the issue, that means that no-one from Microsoft is going to take the initiative to address it until someone posts the right idea.  I thought this was a forum for us to communicate with Microsoft and help improve the product, not a game of cluedo.

Kudo Collector

@tism : right!


@Chakkaradeep :

I will not make a new idea for a bug (or at least a design problem), for which we have 16 pages with examples and suggestions already. Please make a JIRA Ticket (or whatever project and ticket managment tool you use internally) by yourself internally for you and your team mates.


We have enough people who had this problem and are complaining in this existing idea.

And you could also design a own solution for this problem. Perhaps you as sharpoint and flow experts have a better idea as we dumb user.


Beside this, what you pointed out under "this idea" is not exactly the same problem. This is indeed another problem of flow and sharepoint lists and it would help when it would be solved, but it is not directly the same.


Also the idea you pointed out with "this idea" is still open, but a year old. And it is already for a long time top voted, that's right. A good example how long it takes until the top voted ideas will be solved.


I hope for implementations for all the top voted ideas here in the next months. Including the idea here.

Power Automate

@teqs Appreciate your reply and yes we do understand what others have shared in the comments section. For SharePoint trigger specifics, we are tracking with this idea. I hope you can participate there. 

Not applicable

And how did you prevent the integrated "sign-off" flow for a document from looping? It seems this flow can update the column without triggering the flow again.

Regular Visitor


Kindly say when will the solution for "stop self triggering" or avoiding the loop (or whatever name you like) be present in production. 



Resident Rockstar

I create a account for these types of flows ( all flows really ) 

and then put in the following conditional start:




as long as they are not a real user but a service account then they wont interact with the items directly requiring the flow to start. This way you have the best of both worlds, as there may be some reasons to start a loop to simplify your flow design based on conditions for example to start the process again. i.e. if a approval column is set to ReApprove to go back thorugh a process or whatever


Frequent Visitor

Still nothing on this? We just moved to away from 2010 and I had to start using flows. I guess I can just pile this onto why we are looking for alternative solutions. It seems like a lot of "ideas" that are actually poor design or bugs on very simple topics are not addressed and when they are, it is a vague and untimely reply.

Not applicable

Had to revert back to using SP Designer 2013 to accomplish the task.  I started creating a new simple Flow with the intent of updating a column in sharepoint every time it is edited. Then remembered that type of scenario causes a loop. Pretty sad.