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

 

1.png

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.

 

2.png

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

Comments

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.

HTH

Jay

Hey @Jay-Encodian

 

I am experiencing this infinite loop but I couldn't find the option 'Last Updated on' on Update item step. 

 

It seems like Microsoft has changed this feature. Any idea of handling this issue nowadays? 

 

Thank you

 

Hey @rafaelbenicio 

Sorry I can;t see the reference to 'Last updated' in the article? This example uses the 'Modified by Email' value... but in general I'd refer to using trigger conditions now: https://powerusers.microsoft.com/t5/Webinars-and-Video-Gallery/Microsoft-Flow-Trigger-Conditions/td-...

HTH

Jay

HI

Meet Our Blog Authors
  • Experienced Consultant with a demonstrated history of working in the information technology and services industry. Skilled in Office 365, Azure, SharePoint Online, PowerShell, Nintex, K2, SharePoint Designer workflow automation, PowerApps, Microsoft Flow, PowerShell, Active Directory, Operating Systems, Networking, and JavaScript. Strong consulting professional with a Bachelor of Engineering (B.E.) focused in Information Technology from Mumbai University.
  • Encodian Owner / Founder - Ex Microsoft Consulting Services - Architect / Developer - 20 years in SharePoint - PowerPlatform Fan
  • Cambridge UK Power Platform User Group Leader, Technical evangelist and speaker. Always says yes to coffee! #LetsGetCoffee
  • Passionate #Programmer #SharePoint #SPFx #Office365 #MSFlow | C-sharpCorner MVP | SharePoint StackOverflow, Github, PnP contributor
  • I am building business processes and applications that are easy for users' to stick to, so they can follow and understand them. In overall I transform processes to be more reliable and effortless. I am a proud co-organizer of SharePoint Saturday Warsaw and active community member, blogger and international speaker.