Improve Efficiency, Reduce Costs with Trigger Conditions

Trigger Conditions have existed for quite some time, but this functionality was only exposed from Code View in Azure Logic Apps. Recently, the Azure Logic Apps team shipped a user experience within the Logic Apps Designer. In this Serverless Tip, we are going to explore this feature to see how it works.

To illustrate the Trigger Conditions capability, we are going to use a SharePoint list to track expenses. When our expense is more than $100, we want Logic Apps to detect this and then run a process.

As a starting point, I used a template that is in the Logic App Template Gallery that will send an email notification when an item in SharePoint is modified.

As described in the intro, we only want this logic app to fire when the Amount value, from SharePoint, is more than $100. At this point, I need to write an expression. The experience to add the Trigger Condition does not support intellisense so I recommend drafting your expression within a Variable (or Compose) action. In my situation, the correct expression is:

I can now run my logic app and test my expression without worrying about my trigger yet. In our scenario, we should expect a boolean value, of true, to be returned if the amount is greater than $100.

We can see our expression ran correctly, so we can now move this expression to our Trigger Condition by clicking on Settings for our Trigger. At the bottom of all of the options that exist for triggers, we will find Trigger Conditions.

Here we can copy and paste our expression that we formed in our Initialize variable action. Please note that in our Initialize Variable action, we did not need an ‘@’ at the beginning of our expression, but within our Trigger Condition we do need to add this.

We can now test out our expression out by creating a record that is less than $100. When we look at our Trigger History, we determine our logic app checked SharePoint for modified records and found a record that included an Amount of $90 but our trigger never Fired. As a result, our logic app never actually instantiated, and we did not run any downstream actions.

Let’s now test the Happy Path and update a SharePoint record that is greater than $100. When we do this, we discover our trigger will run and it will Fire. As a result, our logic app will be instantiated, and the rest of our logic app actions will run.

So you might be asking yourself, how does this save money? The good news is that it will, the bad news is, it may not be overly significant. As per the Microsoft documentation, “Logic Apps meters each polling request as an execution”. What this means is that;

So any savings that are derived, come from avoiding downstream actions from running. So the alternative of not using a Trigger Condition is that you have downstream actions that check for the Amount coming from SharePoint. If it is more than $100 then you would perform additional actions. This is where you have the ability to reduce costs by filtering out events at the source, as opposed to filtering them out in your logic app which will incur additional action executions.

Conclusion

Using Trigger Conditions, developers can keep their logic app code cleaner and also reduce operational burden by keeping events, that are not relevant, from your Run History. As a result, there are also marginal cost savings that are introduced as a result.