Showing results for 
Search instead for 
Did you mean: 

SharePoint - Managing Recursive Events in Flow

Handling recursive events is an age old problem which can affect any application, moreover it seems to affect SharePoint centric solutions often due to the common need to capture an update event to execute relevant business rules before re-updating the item… which of course is the start of a recursive event (or infinite loop!).

Without delving too far into the distant and potentially irrelevant past… a common approach to handling SharePoint on-premise solutions which could suffer a recursive event, was to disable event firing before updating an item, and then re-enabling event firing… easy, problem solved! Now, fast forwarding a few years you simply cannot do this within SharePoint online as a 'Remote Event Receiver' doesn't expose this capability… I won’t delve into why as it's outside the scope of this post.

A common approach to this solution to prevent recursive events in remove event receivers would be to add logic to verify the user raising the event and determine whether the event should be handled… which is a good approach as typically app only authentication would used by the event receiver and therefor you could simply add logic to not handle events invoked by an update initiated by the app identity.

I hear you say "But Jay, this is a Flow blog why on earth are you harping on about handling recursive events in SharePoint event handlers?"

Because the issue is the same, as is the approach for preventing recursive SharePoint update events in Flow… so, into the detail.

The following flow will create a continuous loop, as the trigger action ('When an item is created or modified') will always be invoked by the 'Update Item' action.



To address this issue I'd recommend creating a dedicated account used as a 'Flow Service Account'. This would allow a condition to be added to the Flow that checked if the update was invoked by the identify executing the update from Flow… and if so, ignore the event, thus preventing a recursive event.

The condition in the example below compares the 'Modified by Email' value of the item updated with the 'Service Accounts' email address… if they are not the same we handle the event, if they are its recursive and therefor we do not handle the event.



Voila! This hopefully provides a robust and simply way to handle recursive events in SharePoint.


When you say "create a dedicated account", is this simply an additional shared email address or does it need to be a full O365 licensed user account?

It'd need to be a licensed account relevant to the action you're performing... the action is using the account to perform actions in O365, it needs a license and assigned permissions to perform those actions.



Meet Our Blog Authors
  • Working daily with Microsoft Cloud to deliver the needs of my company, my customers and various Microsoft communities and forums. | Office 365 | Flow | PowerShell | PowerApps | SharePoint |
  • Co-founder of, Office 365 and SharePoint expert. Passionate about design and development of easy to use, convenient and flexible products.
  • Microsoft Business Apps MVP. Owner of ThriveFast, an Office 365 consulting company.
  • 7x Microsoft Business Solutions MVP (CRM)
  • I'm keen in MS technologies, SharePoint, Office 365 and development for them
  • Daniel is a Business Productivity Consultant & Microsoft Business Solutions MVP who is very enthusiastic about all things Office 365, Microsoft Flow, PowerApps, Azure & SharePoint (Online). Since the preview, Daniel has been working with Microsoft Flow and later on with Microsoft PowerApps. That led to him being awarded an MVP Award for Business Solutions. He loves to blog, present and evangelize about improving productivity in the modern workspace with these amazing tools!
  • Michelle is an Office 365 solution architect in Twin Cities, MN. She has been delivering business collaboration solutions for years with her focus on SharePoint and Office 365. Michelle is a recent board member of the Minnesota Office 365 User Group and has been a member of the SharePoint community since 2009. She is a frequent speaker at MNSPUG and SharePoint Saturday and co-chaired the Legal SharePoint User Group for 4 years. Her most frequent projects have involved rolling out a large deployment of Office 365, SharePoint Online intranet, build of a "CHAMPS" Office 365 user adoption program and most recently, SharePoint On-Premise to Online Migration. Michelle is very excited about cloud technology as it is shifting her IT Pro focus to collaboration strategy and technical adoption.
  • I'm a Microsoft Office Servers and Services MVP with a special interest in SharePoint, Office 365, Microsoft Flow, Microsoft Teams and PowerApps. I work at Triad Group Plc (
  • Passionate #Programmer #SharePoint #SPFx #Office365 #MSFlow | C-sharpCorner MVP | SharePoint StackOverflow, Github, PnP contributor