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.

[StanBaer]

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?

[Jay-Encodian]

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

[rafaelbenicio]

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

[Jay-Encodian]

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

[MooreRNH]

HI

[quietowl]

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.

[Jay-Encodian]

@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

[quietowl]

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