Office 365 – Microsoft Flow – How reliable is Microsoft Flow – Part 2

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.


9 thoughts on “Office 365 – Microsoft Flow – How reliable is Microsoft Flow – Part 2

  1. I find flow is hit and miss occasionally. Although it has been good to me lately.

    One example I can give is a colleague uses flow to run parallel approvals for documents in SharePoint. So when a file of a certain name type is dropped into a doc library it kicks off.

    What we see quiet regularly is the file has not uploaded completely and is in the middle of the save when the trigger is fired. So we get back a file name with a .partial and numbers extension.

    Luckily we have been able to work round it with the documentid link as that is the same regardless. I reported on the community a while back but no resppnse on it.


  2. I also had flows failing where my trigger was a column that changes value (manually). However it would update that column value and trigger the flow, before the rest of the document in the library had saved fully. So very similar to Phillip’s experience…which results in failed flows occasionally when you rely upon complete data. It seems metadata gets saved independent of the file itself with timing, and does not wait for checkin (even when that setting is enforced).


      1. I’ve not seen this but I’ve seen someone else on the forums telling me that there were .partial files created. By checking for .partial at the end of the file name those flows were fixed. Simply exit out and let the flow restart on completion of the file.


Please leave a comment or feedback

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.