Logic App Trigger Conditions

During December’s episode of Integration Downunder, Alessandro Moura showed a recap of the main features that announced for Logic Apps throughout the year. If you didn’t watch it on the day, you should take a look at the webcast.

One of the features that caught my attention, which I haven’t seen before, was the trigger condition. The ability to only fire a logic app if the condition is met. This is great for scenarios where you don’t have control over the event which triggers the logic app (like for example Dynamics 365 triggers, which only allow you to execute a logic app when a record for a given entity has been created or updated), but don’t want to implement the checks within the logic apps itself.

Adding a condition to a trigger is as simple as adding the following property to the trigger json definition, as right now there is no UI defined for conditions (yet, I assume):

"conditions": [{
	"expression": "<logical expression>"
}]

For example, for a logic app to trigger only is the property “status” is set to new or open, the condition would look like this:

"conditions": [
	{
		"expression": "@contains('new,open',triggerBody()?['status'])"
	}
]

Notice that the conditions property is an array of expressions, which means that you can have multiple conditions defined. But be aware that in this case, the Logic App will only trigger if all conditions are met. For example, if you want to trigger a logic app if the status is either new or open and the priority is P1, the condition would look like this:

"conditions": [{
	"expression": "@contains('new,open',triggerBody()?['status'])"
},
{
	"expression": "@equals('P1',toUpper(triggerBody()?['priority]))"
}]

So how about having  if the status contains either new or open or the priority is P1? In this case, you would need a single expression using the OR function, like this:

"conditions": [{
	"expression": "@or(contains('new,open',triggerBody()?['status']),equals('P1',toUpper(triggerBody()?['status'])))"
}]

Here is a sample http request trigger with the conditions property applied for reference:

"triggers": {
	"manual": {
		"conditions": [{
			"expression": "@contains('new,open',triggerBody()?['status'])"
		}],
		"inputs": {
			"schema": {
				"properties": {
					"id": {
						"type": "integer"
					},
					"priority": {
						"type": "string"
					},
					"status": {
						"type": "string"
					}
				},
				"type": "object"
			}
		},
		"kind": "Http",
		"type": "Request"
	}
}

And what happens with the trigger history when the conditions are applied? It will show all the times that the logic app was triggered and in which situations it was fired, like in the example below.

It is also important to notice that the requests (even the ones that didn’t fire) will still be counted for the final billing. So in this case, what is the advantage of this technique anyway?

To start with it will still be probably cheaper -if you do this evaluation inside the logic app it will cost you at least a couple of actions more – the condition, and some sort of indication that your logic app triggered but didn’t executed the main flow – my team usually used Terminate action, with the “cancelled” status to indicate this.

I was never a fan of the cancelled option, because it would flood the run history with cancelled, potentially hiding important info like failed runs. But I didn’t have a better alternative before. This will make our logic apps implementations much cleaner from a management/monitoring point of view.

So far I have tested this on both HTTP and Dynamics 365 triggers. But according to the documentation, it is available to all triggers.

splitOn Behaviour

Many people repoted that this was indeed a feature that was not well known. Esa Vanhahen-Varho reported an interesting detail about this option on twitter. If you apply it on a trigger with splitOn enabled, the condition is evaluated after the splitting, which guarantees that only the array elements that match the condition are fired.

Missed feature to many of us, it seems… Should have hit the bed already but had to try – works also with splitOn, condition evaluated AFTER splitting https://t.co/8OXdwmMRvf

— Esa Vanhanen-Varho (@AzureEsa) December 18, 2018

In this case, you will see one trigger event for the main message and one for each element in the trigger history.

In Summary

• Trigger conditions is a great way to have more control over when a logic app is fired.
• It help you to move logic that would usually be inside the logic app only to define if the logic app can be executed or not to its rightful place, inside the trigger itself.
• Right now, trigger conditions can only be defined in the code view.
• You can define multiple conditions but remember that the logic app will only fire if all conditions match.