SharePoint - Managing Recursive Events in Flow

[Jay-Encodian]

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.