Multiple triggers in a Cloud Flow

It's triggers all the way down - Terry "Flow" Pratchett

But a flow only has 1 trigger, right….right??? Well I thought that too, but a while ago, I was testing out the Copy and Paste functionality and noticed I could copy and paste a trigger. I thought this was so you could copy a trigger to a different flow, but it actually allows you to copy and paste a trigger inside the same flow.

Surely this is a bug, potentially from the new designer as they have been updating it quickly, rolling out new features and fixing bugs. But this is actually by design and certain connectors support multiple triggers inside of a flow, like the Dataverse Connector. But for what reason? Surely you only want a single trigger in a flow.

Usually you are correctly, but sometimes we want to trigger a flow and then need to add do-until loops, re-checking records or polling records to see when something happens, and this is actually a different method to this. So instead of loops counting towards your API counts, a secondary trigger in a flow, will wait until it matches the criteria and then carries on with the flow.

Similarly, if you are separating things into different flows, one with a trigger on create and one on update, these could potentially get merged into a single flow. Reducing the number of flows, reducing solution clutter and maintenance of flows.

Let’s go through a scenario which is quite common and usually needs several pieces of logic and multiple flows for something that is quite simple. You have a flow that is triggered on create of an account record, after it’s creation you need to create some additional records and change some data.

But if the account record contains an account number, you need to integrate it with an ERP system. Historically you would need to handle this in multiple ways. You would need a separate flow to handle the update of the field if it’s populated later, you would also need to have a check condition to see if it’s populated on create and if so, then integrate with it. Or have it in a single flow and have a do-until loop waiting for it to be populated (consuming API calls as it waits) and hope that the column is populated before the timeout on the do-until is reached. Either way, it’s not an ideal situation

Using an additional trigger in the flow, we need a simple check condition to see if the column is populated or not, if it is populated trigger the ERP integration, if it is not, place the trigger and wait until they is successful before triggering the integration

In the screenshot, I filter the 2nd trigger on “modified” and by the account id coming from the original trigger. I also check to see when the account number contains data. It’s important to add such filtering in, if you aren’t filtering on the triggered record, then updates to other records will start this trigger-as-action off.

There are somethings to think about. A flow with a mix of connectors will timeout after 30 days, but if your flow has just dataverse connector, it can continue to run and poll records for 1 year.

There is currently not an enforced limit to the number of your triggers in a flow, however you should consider if the number of triggers are appropriate for what you are trying to do.

The trigger-as-action will continue as soon as it received a single request that matches the trigger and filter conditions, it does not allow for continuing to listen to multiple requests like if the trigger was at the start of a flow. Meaning if you want to capture multiple specific updates, you need to capture them separately and handle it in different triggers or conditions.

Overall, I think this is a cool little hidden gem of Power Automate and Dataverse. Dataverse is the only trigger that I know that supports polling, but others might be available. I also checked and there is no documentation for this right now, but it will be coming in the future.

Ciao for now!

MCJ