cancel
Showing results for 
Search instead for 
Did you mean: 
Jay-Encodian

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

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

Sadly found that this post mainly suggests using service account for executing the looped workflow, which is not helping to normal user who already overwhelmed by complicated SharePoint structure.

 

I take no benefit from it because I, as conventional user, don't have service account.

@quietowl There is no reference to a test account, this simply suggests using a service account. This post pre-dates trigger conditions, I'd recommend using trigger conditions as an alternative

@Jay-Encodian thanks for correcting my wrong reference. Service account is used.

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.
  • I am a Microsoft Business Applications MVP and a Senior Manager at EY. I am a technology enthusiast and problem solver. I work/speak/blog/Vlog on Microsoft technology, including Office 365, Power Apps, Power Automate, SharePoint, and Teams Etc. I am helping global clients on Power Platform adoption and empowering them with Power Platform possibilities, capabilities, and easiness. I am a leader of the Houston Power Platform User Group and Power Automate community superuser. I love traveling , exploring new places, and meeting people from different cultures.
  • Blog site: https://ganeshsanapblogs.wordpress.com/ MCT | SharePoint, Microsoft 365 and Power Platform Consultant | Contributor on SharePoint StackExchange, Techcommunity
  • Encodian Owner / Founder - Ex Microsoft Consulting Services - Architect / Developer - 20 years in SharePoint - PowerPlatform Fan
  • I am the Owner/Principal Architect at Don't Pa..Panic Consulting. I've been working in the information technology industry for over 30 years, and have played key roles in several enterprise SharePoint architectural design review, Intranet deployment, application development, and migration projects. I've been a Microsoft Most Valuable Professional (MVP) 12 consecutive years and am also a Microsoft Certified SharePoint Masters (MCSM) since 2013.
  • Big fan of Power Platform technologies and implemented many solutions.
  • Passionate #Programmer #SharePoint #SPFx #M365 #Power Platform| Microsoft MVP | SharePoint StackOverflow, Github, PnP contributor
  • Web site – https://kamdaryash.wordpress.com Youtube channel - https://www.youtube.com/channel/UCM149rFkLNgerSvgDVeYTZQ/