cancel
Showing results for 
Search instead for 
Did you mean: 

Queuing Flows

I am designing a Flow which refers to a Sharepoint List to retrieve a unique number. After the number is captured, Flow increments the Sharepoint for the next run flow (some sort of a counter if you may). Given that Flow does not queue, I risk the possibility of two successive flows capturing the same number (the increment Action would not be fast enough for the next run). Of course, this would not be a concern if the Flows do queue instead of run simultaneously)

Status: New
Comments
Level: Powered On

This enhancement is crtitical for my team to use MS Flow inplace of Nintex Workflows as we're migrating from the on-prem version of SharePoint to SharePoint Online. 

I have multiple Flows setup for the same SharePoint Intake list.

There are several fields in that list, which when updated a specific way, trigger multiple Flows to create intakes on different SharePoint lists.

Once the item on the corresponding SharePoint list has been created, each Flow is setup to update the original Intake to stop the Flow from triggering in a loop.

The problems begin when updates are made to the original intake that end up triggering several of these Flows.

Since they are each setup to update the original Intake, each Flow updates the original item, which causes these Flows to trigger again.

The order in which the intake is updated, is what's throwing everything off. 

Upon testing, this causes new items to be created multiple times, instead of just once, before each Flow has had a chance to update the field in the way that stops that specific Flow from triggering again.

This also creates Save Conflicts because changes made by multiple Flows conflict with those made concurrently by another Flow.
The issue appears to be caused because the Flows run simultaneously instead of concurrently, after each one is completed.
 
This is a very complex situation but I'm going to attempt to give a real-world example that's easy for anyone outside of my organization to understand:
lets say I have a Flow that has 2 columns that can trigger a Flow and 2 reference columns that are to be updated to reflect that the Flows have run (to stop the loop).

Example scenario: 
Column A is changed to "Communication Needed" and Column B is changed to "Document Needed" in a SharePoint item.

I have 2 Flows setup to run when a SharePoint Item is Created or Modified.

Flow #1 has a Condition to look for "Communication Needed" in Column A, and a secondary Condition that Column X does not equal "Communication Request has been completed".
When both of these conditions are met, it creates an item on a 2nd SharePoint list for a communication task to be completed. 
Then Flow updates Column X in the original SharePoint Item to "Communication Request has been completed" to reflect that this action should not be created again if/when the SharePoint item it modified again.

Flow #2 has a Condition to look for "Document Needed" in Column B, and a secondary Condition that Column Y does not equal "Document Request has been completed".
When both of these conditions are met, it creates an item on a 3rd SharePoint list for a document to be created. 
Then Flow updates Column X in the original SharePoint Item to "Document Request has been completed" to reflect that this action should not be created again if/when the SharePoint item it modified again.

Since the SharePoint item was modified, both Flows are triggered simultaneously. 

If Flow #2 completes and updates the original SharePoint item before Flow #1 has a chance to complete, the change will trigger both Flows again since the item was modified. 

Because Flow #1 hasn't completed it's first run yet, Column X that should reflect that a Communication Request has already been completed, isn't reflecting that change yet. 
This results in the second run of Flow #1 to meet the conditions necessary to create a new Communication Request on the 2nd SharePoint list.

At this point in our scenario, the first run of Flow #1 is still in progress. 
Once it completes, it will create another item on the 2nd SharePoint list for a Communication Request. 
(THE ABOVE LINE IS THE ISSUE.)
The Flow will then update the original SharePoint item to reflect that a Communication Request was completed.

This update will once again trigger both Flows, but this time, neither will meet the Conditions required to create an item on those related SharePoint Lists, and our loop would be complete.