Microsoft Power Automate Flow Trigger Conditions

It’s common to use the ‘When an item is created or modified’ trigger when creating Flows for SharePoint with Power Automate. This can be a very chatty trigger as every change can result in the Flow executing. Users can utilize Conditions, Scopes, and Run After settings within the Flow logic to determine if they should really act on an item. This still results in yet another unhelpful entry within the Run History.

Leveraging Trigger Conditions offers the option to check Trigger Properties and additional logic to determine if the Flow should run at all. Users can continue to use the same Trigger while streamlining both Flow logic and Run History.

Trigger Conditions are found by selecting the menu from the three dots or ellipsis in the upper right-hand corner of the Trigger Card. Once there, look to Settings, then at the bottom, Trigger Conditions. Users can add more than one Condition and that the Trigger will only run when the Conditions of which at least one must evaluate as True.

Since the Dynamic Content menu isn’t available at this point, users must use the available Functions. Whatever expression is entered should return a Boolean value. A non-Null value like an Object or Number won’t allow the Flow to run at all.

Note that List One which has two Content Types with differing Fields. Item has only the Title column and Item 2 adds the Example column.

Normally, users would have no means of filtering processed items within the Trigger with When an item is created or modified as no OData filtering is provided. By using the following Trigger Condition, users can ensure Flow doesn’t process any items where Example is missing data.

Two Compose actions are added to show the values of the Content Type and Example properties of the triggering items. When the Test functionality is used, three scenarios can be run:

Item Content Type:

Create a new Item which has only the Title column; no processing should occur.

Item 2 Content Type Without Example Value:

Create a new Item 2 which has both Title and Example columns, complete only the Title; no processing should occur.

Item 2 Content Type With Example Value:

Create a new Item 2 which has both Title and Example columns, complete both; the Test should now fire and process the Trigger.

Here are the results showing the Item 2 Content Type and the text from the completed Example field:

Alternately, we could use the Content Type itself as the Trigger Condition:

@equals(triggerBody()?[‘{ContentType}’]?[‘Id’], ‘0x0100ACFF228D0E467842B04850DDAE19C31C00BBAE74759D28534CB0A8EEAFC9908541’)

Trigger Conditions can be grouped to create complex AND/OR logic. While adding multiple conditions acts as an AND, where all must be True, there is no UI method for OR. Adding @false as a secondary condition illustrates this as if we run a Test — it will never trigger. 

Fortunately, Microsoft has provided both and() and or() logical comparison functions, allowing the introduction of OR in a single condition.

@or(equals(triggerBody()?[‘{ContentType}’]?[‘Id’], ‘0x0100ACFF228D0E467842B04850DDAE19C31C00BBAE74759D28534CB0A8EEAFC9908541’), not(equals(triggerBody()?[‘Example’], null)))

With this condition, the Flow would fire only if either the Content Type is Item 2 OR Example isn’t empty. This would run anytime the Content Type was Item 2, regardless of the value for Example, as well as for any other Content Type so long as Example isn’t empty. Tests do not fire when the Trigger Condition isn’t met, which means no more Run History entries when no real processing occurs. 

Condition Breakdown:

@: Allows the use of a Function within an Expression (anytime it isn’t entered via the Dynamic Content / Expression menu).

or(<expression1>, <expression2>, …): Return true when at least one expression is true. Return false when all expressions are false.

equals(‘<object1>’, ‘<object2>’): Return true when both are equivalent. Return false when not equivalent.

not(<expression>): Return true when the expression is false. Return false when the expression is true.

[, ], and ?: These operators are used to navigate data structures. In addition to accessing indexes in an array, the square brackets also allow access to Properties or Keys.

For users currently filtering on Trigger properties with Action Cards, it’s recommended to use Trigger Conditions instead. Users can even leave your existing logic in place as a matching condition would ensure that the same values are passed. They work particularly well in instances where Flow may trigger itself, such as updating a column value when a List Item is modified. In organizations with complex Flows or a large inventory, Trigger Conditions can cut down on Nesting Depth, Actions Per Flow, and Flow Executions — all of which contribute to staying within service limits and getting the most value from your subscriptions.