Today I ran a couple of tests comparing Microsoft Flow with SharePoint Designer Workflows and I found a number of interesting differences in the way the two engines work.

In my tests I looked at SharePoint Designer Workflows 2013, SharePoint Designer Workflows 2010 and Microsoft Flow when creating and updating list items at high speed.

I started by creating two lists.

  • ReliabilitySource
  • ReliabilityDestination

I also created a PowerShell script that creates items 100 within the ReliabilitySource list and then updates these items.

if ($cred -eq $null)
{
$cred = Get-Credential -Message "Please supply password" -UserName "user@mytenant.onmicrosoft.com"

Connect-PnPOnline -Url https://mytenant.sharepoint.com -Credentials $cred
}

$List = Get-PnPList -Identity ReliabilitySource

for($counter=0;$counter -lt 100; $counter++) {
$item = Add-PnPListItem -List $List -Values @{"Title" = "Created" }
Set-PnPListItem -List $List -Identity $item.Id -Values @{"Title" = "Updated"; "Counter" = "$counter"}
}

Note that I’m first creating the item with the title created and then setting the title to updated. During my (work)flows, I’m using the title to check if a the trigger was on the creation or update or both by creating list items in the ReliabilityDestination list.

 

Then within SharePoint Designer I created two workflows.

The SPD 2010 version:

and the SPD2013 version:

and finally I created a Flow:

Time to run my tests!

 

Until I introduced SPD 2010 workflows my PowerShell script worked well but when the 2010 version of the SharePoint workflow engine gave me some Version conflict errors in my script as SharePoint Designer updates the status fields on the SharePoint list:

Set-PnPListItem : Version conflict.
At U:\test.ps1:16 char:4
+ Set-PnPListItem -List $List -Identity $item.Id -Values @{“Title” = …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : WriteError: (:) [Set-PnPListItem], ServerException
+ FullyQualifiedErrorId : EXCEPTION,SharePointPnP.PowerShell.Commands.Lists.SetListItem

 

To resolve the above I added the following lines after my Set-PnPListItem line in the original PowerShell script:

if ($? -eq $false) {
Set-PnPListItem -List $List -Identity $item.Id -Values @{"Title" = "Updated"; "Counter" = "$counter"}
}

Once the above fix/workaround was applied I found that the 3 engines behaved very differently. When designing your workflow solutions you should take these things into account. I ran my tests a few times, but I got similar results all the time.

Quite quickly I got the following results.

  • SharePoint Designer 2010 triggered 66 times on the creation of an item and 106 times on the update of an item.
  • SharePoint Designer 2013 triggered 1 time on the creation of an item and 30 times on the update of an item.
  • Microsoft Flow  triggered 17 times on the creation of an item and 118 times on the update of an item.

As I only created 100 times it looks like even though the triggers on the creation go off the updated values of the item that triggered the (work)flow may be used. This seems to be the behaviour when any of the engines get under pressure. This doesn’t have to be a problem, but it is something to consider when designing/developing your (work)flows.

Then after a while I checked again.

It looks like all the engines are still catching up.

I would have hoped to get 100 Created and 100 Updated items. With the assumption that workflows might use updated data I would at least hope that there are 200 items created by each (work)flow engine.

As I wait longer still more items are being created:

Somehow I’m seeing 249 items created by my SharePoint Designer 2010 workflow; 109 items created by my SharePoint Designer 2013 workflow and finally 214 items created by Flow.

As I want to make sure that the workflow engines aren’t affecting each other I’m then rerunning my test script another 3 times and this time I will only have one (work)flow activated at any one time.

 

SharePoint Designer 2013 Workflows

The SharePoint Designer 2013 Workflows again seem to wait at about 30 instances. So it looks like in Office 365 SharePoint Designer workflows are being throttled at 30.

And after a while more updates are coming through:

 

and after a while (about 15 minutes) we’re seeing all jobs finished.With the throttling and a timer job that seems to sort out the workflow runs every 5 minutes the performance will be ok for quiet systems but when SharePoint Designer gets busy we still get the same double results.

SharePoint Designer 2010 Workflows

SharePoint Designer 2010 seems to be a lot better than its 2013 sister. SharePoint 2010 is almost able to keep up with my script and there is no throttling like in SPD 2013 and it is also able to keep up with both creation and updates of list items.

Still quite a few Creation items were missed but at least the Update events were picked up.

Microsoft Flow

I then disabled my workflows and enabled my Flow and …

That is weird flow is catching up! and after a while it got all of the updates on my items. It looks like Flow is cleverer than I thought. This is where flow keeps hold of a ChangeToken. This could be useful or very dangerous.

Then I cleared up my Destination list again and ran my script again with just the Flow enabled.Once again no throttling happening with flow like we saw with SharePoint Designer 2013 workflows.

 

All 100 items updated were picked up. I ended up with 106 update items as 6 times when my script generated a triggering item flow was too slow to get the item details before the update. 14 times the creation triggered a flow and flow was able to collect the item details before the the item was updated.

Conclusions

When you have SharePoint list items that trigger a Flow and they are frequently updated you might not want to rely on the creation of list item. If you just create items and the items aren’t immediately updated Flow is able to keep up with the item creation as expected, however When I only triggered on the creation of the item I did end up with too many items:

None of the triggers were missed, however sometimes flows triggers multiple times on the same item therefore when triggering on the creation of items it feels similar to the retry issues that I  dislike so much in SharePoint Designer and this is something to be aware off when building your flows. It is of course a lot easier to handle this situation within Flow as its error handling options are far superior to SharePoint Designer workflows.

 

 

 

 

 

Advertisements