Trigger Conditions in Power Automate were a great addition released in mid-2019. They are designed to stop your Flow (Automation) from running if the conditions are not met. Prior to this being released, you would need your automation to run and then you handled the condition whilst in flight. In the days where we had a pot of Flow runs, we would have automations running and spending our quota without actually delivering any value. Trigger conditions protect us from that.
Within this blog we'll look at how we can quickly and easily create our trigger conditions so that we know they are working. I can speak from experience that there's nothing more frustrating than trying to figure out the condition, and testing it by running your Flow and then not knowing truly whether it is correct or not.
When I create my variable, it will need to be of a type Boolean so that I can see whether it is going to return true or false. I effectively test my condition both ways to ensure that my expression is yielding the result I expect, therefore in this scenario I will trigger my automation from the SharePoint list, first of all selecting the RunAutomation as Yes, and then setting the RunAutomation to No.
In this example, I am testing the expression:
equals(triggerBody()?['RunAutomation'],true)
Once I am sure that the expression is working as I want, I can then take the expression and place it into the trigger condition. The one addition I need, is to add the escape character at the start which is the @ symbol. Therefore my trigger condition will be:
@equals(triggerBody()?['RunAutomation'],true)
With this condition now in place, the automation will only run when it equates to true, i.e. only when RunAutomation is set to yes. Once I've set the trigger condition, I can then remove the test variable.
The trigger condition takes the format of an expression, and must evaluate to either true or false. If it evaluates to true then the automation will run, otherwise it will ignore the trigger event.
The easiest way of being able to test this is by creating a variable as a Boolean within the automation, usually directly below the trigger which will allow you to write your expression and then test it. Ensure that you run the automation to test both positive and negative paths to ensure that your expression is evaluating to the correct result each time. Once that's done, you can past it into the trigger condition and then add the escape character @.
I hope you found this blog useful, and as always, feedback is very much welcome.
Within this blog we'll look at how we can quickly and easily create our trigger conditions so that we know they are working. I can speak from experience that there's nothing more frustrating than trying to figure out the condition, and testing it by running your Flow and then not knowing truly whether it is correct or not.
How trigger conditions work
The first thing for us to understand is how the trigger conditions work. Effectively they work in the same way as an expression, whereby we provide it with a function name, some parameters, all done to determine an outcome of TRUE or FALSE.
As an example, I have a SharePoint list with a field called RunAutomation as a Yes/No field. I only want the automation to run if the field is set to YES. Therefore I need to use an expression to test for that, and for this comparison I need to use the function "equals":
@equals(triggerBody()?['RunAutomation'],true)
If you're happy with writing expressions, then you can crack on and just write it straight into the trigger condition. But if you're not so confident or you want that piece of mind that it's going to work first, then we can keep it simple and use Power Automate to confirm our logic.
Keep it Silly Simple
When ever I am creating my trigger conditions, I always create the expression within my automation first of all. This will allow me to evaluate whether my condition is going to work, and that I'm getting the desired results. Normally this is the first thing I will do, however we can do this later if we need to. I normally place an Initialize variable action directly beneath the trigger and then use that to write my expression.
In this example, I am testing the expression:
equals(triggerBody()?['RunAutomation'],true)
@equals(triggerBody()?['RunAutomation'],true)
With this condition now in place, the automation will only run when it equates to true, i.e. only when RunAutomation is set to yes. Once I've set the trigger condition, I can then remove the test variable.
Finally...
We have looked at what a trigger condition is, the ability to evaluate a value from the trigger which will determine whether the automation will run or not. This is a much more efficient way of doing this rather than doing the check once the automation has started.The trigger condition takes the format of an expression, and must evaluate to either true or false. If it evaluates to true then the automation will run, otherwise it will ignore the trigger event.
The easiest way of being able to test this is by creating a variable as a Boolean within the automation, usually directly below the trigger which will allow you to write your expression and then test it. Ensure that you run the automation to test both positive and negative paths to ensure that your expression is evaluating to the correct result each time. Once that's done, you can past it into the trigger condition and then add the escape character @.
I hope you found this blog useful, and as always, feedback is very much welcome.
Great explanation. Thank you for sharing!
ReplyDeleteHello - thanks for your post. How could I write a trigger function in the settings, like you've illustrated, to run the flow only if the new email comes from a specific email address. If it's relevant, the email address is outside of my domain (ie. an "external" email address). Thanks!
ReplyDelete