After yesterday’s post, How reliable is Microsoft Flow?, today it is time to look at the reliability of triggers.

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:

Reliability of triggers in Power Automate Microsoft Office 365 flowitem

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:
Reliability of triggers in Power Automate Microsoft Office 365 itemscreated

and as the items are created my email alerts are coming in quite quickly. If you want to know more about PnP PowerShell creating items then please read all about Add-PnPListItem.

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

High Reliability of triggers

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.

Reliability of triggers

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 Power Automate it is important to realise how your Flows are triggered.

Avatar for Pieter Veenstra

By Pieter Veenstra

Business Applications and Office Apps & Services Microsoft MVP working as a Microsoft Productivity Principal Consultant at HybrIT Services. You can contact me using

9 thoughts on “Reliability of triggers in Power Automate”
  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.

Leave a Reply

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