cancel
Showing results for 
Search instead for 
Did you mean: 

Power Automate Trigger Conditions made EASY

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.

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)

 

 

 

Trigger done.PNG

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.

Trigger Confirmation.PNG

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)

 

 

 

True Run.PNG

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.

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.

Comments

So there really isn't anyway for it to look for an event like "when this field is updated" and have that evaluate to true or false? 

If no, then really the only way to determine if a field has updated is to store its old or new value (perhaps in a hidden field) and compare the two?

This is the issue I'm trying to address here:

https://powerusers.microsoft.com/t5/Building-Flows/Trigger-when-specific-field-is-updated-as-opposed...

Is the syntax the same for the trigger condition if the value you are testing is a text field? 

 

 

True values work great but mine get stuck on the false values. The test just spins and spins. Is there some kind of "end" or "stop" that I need to add?

Hi, I am trying to implement your solution and I'm running into a syntax error. The column that I need to check (DaystoExpiry) is a calculated column - is this why it won't work? All the values in the DaystoExpiry column are integers. I'm trying to use the LESS function instead of EQUALS, but otherwise I'm following your steps exactly. The condition to trigger the flow is a value less than 30. The flow works otherwise (it sends me an email every day when my today's date column is updated). Any help would be appreciated! 


Edited: my variable expression is this: 

less(triggerBody()?['DaystoExpiry'],30)
 

sharepoint flow 17 august.png

 

What about "Not Equals" what do I use for that?

 

@rmcintyre14 You're getting a null value in DaysToExpiry, you probably need to review THIS article.

 

@iMrAdam try @not(@equals(EXPRESSION))

ishraqiyun77

Actually you can trigger a flow when a field changes. I use this trigger condition PRECISELY for that reason

Example: you have a list of projects and you want to notify the PM when the project status changes to Closed and ONLY when it changes. Any other edits made after the project is closed should NOT generate an email.

  1. Turn on version control for your list
  2. Use trigger "when an item is modified" and add a trigger expression so that the flow runs ONLY if [STATUS] = closed
  3. Use the new "Get changes for an item or file (properties)" action to target the [STATUS] column for changes
  4. Condition If [Has STATUS column changed] = true (in small letters. The condition will fail if you use "True")

See MSFT documentation on it here https://docs.microsoft.com/en-us/sharepoint/dev/business-apps/power-automate/sharepoint-connector-ac...

 

This has been a GODSEND to me for simplifying my lists and drastically reducing the number of flows runs as it only runs if the expression is true.

Meet Our Blog Authors
  • Experienced Consultant with a demonstrated history of working in the information technology and services industry. Skilled in Office 365, Azure, SharePoint Online, PowerShell, Nintex, K2, SharePoint Designer workflow automation, PowerApps, Microsoft Flow, PowerShell, Active Directory, Operating Systems, Networking, and JavaScript. Strong consulting professional with a Bachelor of Engineering (B.E.) focused in Information Technology from Mumbai University.
  • Encodian Owner / Founder - Ex Microsoft Consulting Services - Architect / Developer - 20 years in SharePoint - PowerPlatform Fan
  • Cambridge UK Power Platform User Group Leader, Technical evangelist and speaker. Always says yes to coffee! #LetsGetCoffee
  • Passionate #Programmer #SharePoint #SPFx #Office365 #MSFlow | C-sharpCorner MVP | SharePoint StackOverflow, Github, PnP contributor
  • I am building business processes and applications that are easy for users' to stick to, so they can follow and understand them. In overall I transform processes to be more reliable and effortless. I am a proud co-organizer of SharePoint Saturday Warsaw and active community member, blogger and international speaker.