Use Trigger Conditions with your Power Automate flows to reduce unnecessary flow runs and costs.
Control condition blocks
A common requirement in Power Automate flows is to check that some condition is satisfied before continuing with the useful work of the flow – we’ll call this the Start Condition.
If the start condition is not satisfied the flow should immediately terminate.
To implement this start condition, Power Automate Condition blocks are often used.
With a condition block, Power Automate will test if a statement is true. If the statement is true then Power Automate will continue executing the steps in the If yes block, otherwise it will continue with the If no block.
When this pattern is used, the control block will be one of the first steps executed and the If no block will normally be empty meaning no useful work is done by the flow if the condition is not satisfied.
This approach to the requirement works, but it does have some disadvantages.
Firstly, the Power Automate had to run the flow in order to test the start condition to see if it should continue with the following If yes steps.
Every time a flow runs, it create an entry in the flow’s history. If later you need to examine the steps taken of a previously run flow, it may be difficult to the specific flow run you need in the history list among all the flows that failed the start condition.
The flow history has become noisy.
Secondly, depending on your licensing, you may be charged for each flow run. All those flow runs which failed the start condition could be costing you money.
It would be better to stop flows which will fail the start condition from running at all.
Trigger conditions
Power Automate provides a feature called Trigger Conditions which are used to constrain the conditions under which a trigger can fire.
We can use trigger conditions to test our flow’s start condition and prevent unnecessary flow executions.
Trigger conditions can only base their decision on information available to the trigger. They cannot make any further API calls – such as reading from a SharePoint list or calling the Graph API – to help in evaluating the start condition.
Example: Probabilistic creation of SharePoint list items
No blog post is complete without a contrived example to help demonstrate its topic.
In this post’s example we will have a Recurrence Trigger fire every minute. Each time the flow is fired, it shall randomly decide whether it should create a new list item in a SharePoint list with a probability of 20%.
The above screenshot shows how we might implement the decision to create the list item within the flow. But that approach means that 80% of our flow runs will not do any useful work, may still have a cost associated with their execution, and will create noise in the flow history log.
To avoid these disadvantages, we shall implement the flow with Trigger Conditions so that it only runs for 20% of the potential recurrence trigger firings.
Create the flow with a Recurrence Trigger, using a 1 minute interval.
Next, add the Create Item action to create an item in a SharePoint list of your choosing.
If this flow is saved and enabled it will add an item to a SharePoint list every minute, but we only want the flow to create an item with a probability of 20%.
To configure trigger conditions on the recurrence trigger, click the ellipsis (…) on the trigger and choose Settings from the pop-up context menu.
On the settings dialog for the trigger, click the Add button to add a new trigger condition.
A trigger condition is an expression that must evaluate to true for the trigger to fire.
If multiple trigger conditions are added, they must all evaluate to true for the trigger to fire.
Enter the following as the trigger condition expression
@equals(rand(0, 5), 0)
For trigger conditions, the expression needs to be prefixed with the @ symbol. (This is due to how power automate finds, evaluates and replaces expressions in the underlying workflow definition for the flow – See Microsoft’s documentation on the Workflow Definition Language for more information)
Lets breakdown the expression entered as the trigger condition.
rand(0, 5)
The above (sub) expression calls the rand function to generate a random integer (whole number) which is greater than or equal to 0, but also less than 5.
This is effectively the same as picking a number from the list, [0, 1, 2, 3, 4].
equals(rand(0, 5), 0)
In this expression, the equals function is called to compare the result of rand(0, 5) to 0.
If the random number is equal to 0 then this expression will return true, otherwise it will return false.
Using this expression as the trigger condition means the trigger will only run when the randomly generate number is 0, which is expected to occur with a probability of 20%.
Testing the example flow
To test the above flow with trigger conditions, a new SharePoint List was created and the Create Item action in the flow configured accordingly.
The flow was enabled for 24 hours. If there were no trigger conditions configured on the flow then that would amount to 1440 flow runs in that 24 hour period, resulting in 1440 items created in the SharePoint list.
Since the flow’s trigger conditions should only allow the trigger to fire with a probability of 20%, we should expect to see approximately 288 item (1440 item * 20%) in the SharePoint list.
In the above screen shot we see that 299 items were created over the 24 hour period that the flow was enabled.
This means that the low was run with a probability of 20.8% which is a very close to the desired probability of 20%.
Conclusions
Trigger Conditions offer a way to use the same expressions used in condition blocks to control whether a flow will run.
This avoids unnecessary flow executions, reduces noise in flow logs and can save money.
