I see a lot of flows passing by that have all the logic within the flow itself. You can optimize the flow by applying trigger conditions. Responses can also come in handy when developing a Power Automate flow. So that's the focus for this month.
Challenge Objectives
🎯 Understand how to implement trigger conditions
🎯 Know the impact of responses
🎯 Have better performing flows
Introduction to Trigger Conditions
A common Power Automate pattern is to use logic at the start to determine if the flow should proceed or stop. But did you know there’s a cleaner and more efficient way to handle this logic? You can avoid bloating your flow with extra conditions and prevent unnecessary flow runs. This is where Trigger Conditions come in.
Trigger Conditions allow you to add simple checks directly to the trigger, letting you control when your flow runs based on specific criteria. This means your flow won’t even start unless the conditions are met, leading to improved performance, reduced flow runs, and less cluttered logic.
Leveraging Trigger Conditions is a key skill for building professional and efficient Power Automate solutions.
Use trigger conditions on SharePoint Lists
Let's start with an example that has a pattern that I see all the time. A SharePoint list is created, and based on one field, some actions must be executed. For this example I use the SharePoint list template Work progress tracker. The scenario for this part is that we want to send a notification to our own Microsoft Teams Team General channel when a work item is created with Priority Critical.
The image above is an example of the flow that could be created. However, this flow runs for every created item, even if the priority isn't Critical.
On the images above you can see that this flow got triggered, which does the evaluation, and then nothing happens. Such a waste of compute power.
Now go into edit mode again of your flow and open the Settings of your trigger.
On the bottom of this panel you will see Trigger Conditions. You can add one.
This section needs an expression. You can enter the following.
@equals(triggerOutputs()?['body/Priority']?['Value'], 'Critical')Save the flow and now create two records. One with priority Critical, and one without any priority entered. You should see that only the one with Priority Critical triggered the flow.
Because we now have a condition in the trigger, we can remove that logic from the actions section.
See how easy the flow becomes. Lovely. Now the question is how you can get this expression. To be fair, I just asked ChatGPT to give me a trigger condition. f you have a ChatGPT license too, you can use the Custom GPT I created.
Another option can be found on Microsoft Learn. You can add a Filter Array action, and specify your logic in the interface. Sorry for showing it in the new designer. I guess I am the only human being that is a big fan.
When you navigate to code view, you will see the expression.
You can just copy the expression in the where parameter and paste it in the Trigger Condition section. You can then obviously remove the Filter Array action.
If you wonder why the first is on triggerOutputs() and the second on triggerBody(), I have to say that you have a very good eye. The Body is a part of the triggerOutputs(). When you view the raw outputs of the trigger, you will see a bunch of headers, and the body. With the TriggerOutputs(0 option, you could even trim the flow runs based on the headers. As the Priority can be found in the body, they both work. Good to know.
The Trigger Condition option works on basically every trigger, so you can implement your new skill on almost every flow from now on.
Use Trigger Conditions on Dataverse
Dataverse triggers have some special power. Yes, these trigger can also use Trigger Conditions. But you can also see a FIlter rows option, which basically acts as a trigger condition.
The hint text states that we need to enter an Odata expression. In this situation I highly recommend FetchXML Builder in XrmToolBox. If you have never heard of it, XrmToolBox is a client application that connects to Dataverse. You can use a wide range of tools, where FetchXML Builder is the most downloaded tool.
FetchXML Builder is perfect for querying Dataverse. FetchXML is the proprietary XML based language to query Dataverse. With FetchXML Builder you can simply create a query with an interface. This way everybody can create these FetchXML queries.
But it has some amazing additional features. One of those we can use in this scenario.
As you can see on the image above, I have created a simple query with the interface to only retrieve contacts where the firstname starts with an A. You can execute the query to retrieve the output, and you can see the actual FetchXML query. But we can also convert the query. We used The OData conversion when we wanted to get an overview of Failed Flow runs in Challenge 031 | Failed Flow Runs. But now we can just get the Power Automate parameters.
Just click on it to copy and paste it in your Power Automate trigger.
The end result is as simple as shown in the image above.
I personally prefer the second option for Dataverse, as it is super clear. The trigger conditions are a bit too hidden to quickly understand the flow. You can add a note, but this is subpar. Another advantage is that with the Odata option we can also filter on related records. This way a more complex filtering can be achieved.
Both options are a way to limit and improve your flow runs.
Responses
The second part of this challenge focuses on Power Automate Responses. While Trigger Condition helps you optimize the start of a flow, Responses help you optimize the flow's ending.
Responses are used to provide output from a flow to the end user. Responses make your flow synchronous, meaning the flow waits until it has completed certain actions before sending a response. This is different from the default asynchronous nature of Power Automate flows, where actions can continue running even after the flow has started processing. It is good to mention that the synchronous option (so waiting for a response) can take a maximum of 2 minutes, but that is still quite a long time from a user experience perspective. The a-sync option has a default max runtime of 30 days.
So, when should you use responses? If your flow is part of an interaction where the end user expects immediate feedback, such as on a form submission in a Power App, using a response makes sense. For instance, you may want to return a status or confirmation message to the user after performing some quick checks. On the other hand, if the flow is fully automated and there is no immediate need for user feedback, you can allow it to run asynchronously without a response.
One powerful approach is to use a response to provide quick initial feedback to the user and then let the flow continue running asynchronously after the response is sent. This way, you ensure the user receives timely feedback while still allowing more complex or time-consuming actions to proceed in the background. This pattern is especially useful for scenarios involving quick initial checks that can determine whether further processing is necessary.
I conceptualize this as a Trigger Condition where not all the required information can be found in the trigger body (or outputs).
The whole idea for this challenge came to mind when my colleague Thomas van der Waard asked me to double-check on his approach for a Power Automate flow. Together we came to the idea of running some quick checks, respond the findings, and then proceed with the actual actions.
To add some context, we wanted to create a Power Automate flow that we can use to quickly set some user settings, which are Dataverse records. for re-usability, we opted to make it a manually triggered flow and ask for some user input. Those inputs are the environment ID, and a Schedule Datetime. The environment GUID is an input for the Dataverse connector, and the DateTime is used to make the flow wait until that exact moment. This way we can schedule changes.
The flow we created is shown below.
What you can see is that we used 4 response actions. Note that the Response | Invalid Environment is set to run after the Get Environment as Admin action has failed (red dot in this lovely new designer). The parameters of the response are shown below.
we gave the Status Code a 404, as that is the Not Found option. You can find the different status codes here. We did the same error handling concept on the Date side. And yes, I did notice that i can optimize the flow run by first looking at the date rather than looking at the environment ID, as the date is in the trigger outputs, so no additional API call has to be made.
Now we get to the cool part of these responses. Create a similar flow on your side, and run the flow manually. You will get a form with the input parameters.
I entered the following. As you can see I did not enter a valid GUID. Let's see what happens?
Within a second, I get the response back and Power Automate tells me it cannot run the flow. We did enter our own errorMessage. If you are using this flow in a Power Apps, you can fetch that output and use that in your interface. But I thought it was very cool that we can use these responses to add some validation on the input parameters of the default form in Power Automate. We also added a terminate with the Cancelled option, to get some grip on the flow runs. We use Failed in our monitoring as described in Challenge 031 | Failed Flow Runs, so we want to stay away from that. Cancelled is a neat option to quickly see which flows got cancelled and which ones proceeded.
So to be fully clear, we do a quick check if the input parameters are correct, if so, it proceeds. If not, it will throw an error in the response.
Using the Trigger Condition and the Response is not only good practice for improving your performance, but also great for incorporating error handling. Especially the Response option. We are all focused on making the flow do exactly what it should do. The happy flow. But things can go wrong. Implementing your own error handling instead of the default provided by Microsoft (Failed) will not only improve the performance, but also the effectiveness of your flow.
Additional Information
Implementing a Try-Catch concept in your Power Automate flow is another great example of making your flows more effective. You can find loads of examples online.
Key Takeaways
👉🏻 Use trigger conditions to prevent unnecessary flow runs, improve performance, and keep your flows clean.
👉🏻 Use responses to make flows synchronous when immediate user feedback is required, providing a better user experience.
👉🏻 Combine synchronous responses with asynchronous processing for optimal performance and timely user feedback, especially for scenarios with initial checks followed by background actions.