After yesterday’s post, How reliable is Microsoft Flow?, I thought maybe I should make my tests a bit more reliable.

During this series I’m going through my conclusions as I try to get to developing reliable Flows.

Posts in this series:

Part 1 – Twitter feeds turned into emails

Part 2 – SharePoint lists alerts with Flow

Part 3 – Reliable Flows

Part 4 – Error Handling


I want to make my system very busy end then see if Microsoft Flow can keep up. So in this post I’m going to take the next step. I’m going to create 100 item in a SharePoint list using PowerShell. Then I’m going to trigger a flow on the item creation and send myself an email for each of the items.

So my Flow looks like this:

All quite straight forward.

Now the PowerShell script:

$siteUrl = ...
Connect-PnPOnline $siteUrl
$web = Get-PnPWeb
$list = Get-PnPList -Web $web -Identity testlist

For ($i=0;$i -lt 100; $i++) {
   Add-PnPListItem -List $list -ContentType "Item" -Values @{"Title" = "Test Item $i"}

Then my items are being created:

and as the items are created my email alerts are coming in quite quickly.

This is a lot better than yesterday’s test results. Even the run history is giving me a 100% success rate.

The conclusion today is a lot better. So maybe I should rename my posts and check each connector. It looks like yesterday’s trigger based on Twitter wasn’t very reliable whereas the SharePoint list connector is very good.

So why is one better than the other.

It’s all based on the trigger mechanism that is used. When triggering on the creation of a list item there is a data driven process. Therefor the data is always available. Yesterday’s Twitter Trigger was time driven. Every X minutes checking if there is something to do and then handle all data that is coming in is slightly harder as there might not be any data to handle, hence the error messages that appeared.

Therefore when building flows in Microsoft Flow it is important to realise how your Flows are triggered.