Let’s start with a simple one, even though we are not big fans of using the trigger ‘When a row is modified’ in Dataverse, we sometimes use it as functional consultants. It sometimes is a little bit buggy, we therefore use HTTP requests a lot, we will talk about that later.
Easily create your trigger condition with Filter Array
Lets say you want to send an email when the status of an account changes from ‘Pending’ to ‘Active’.
We start with the step when a row is added, modified or deleted and choose Modified, the Accounts table and Scope Organization. When you are not sure how to build your own trigger condition, you can add a step called ‘Filter Array’, select the field which you want to use in your trigger condition and enter 1 as the optionset value which belongs to the Accounts Status Reason. Then click on Edit in advanced mode to show the trigger condition and simply copy paste it in your trigger condition.
That’s it! We now are 100 % sure that the trigger condition is met and the cloud flow should always fire.
Use first instead of apply to each after a list rows
I have seen a lot of cloud flows in which I had to expand a lot of ‘Apply to Each’ steps. We encounter this behaviour a lot when we use the Dataverse step ‘List Rows’. Usually this is done to iterate through each of the items in the List Rows step. Sometimes we also use a List rows with multiple conditions and only retrieve 1 Row by using a Fetchxml query. Then we can work arround the apply to each by using and expression and use the ‘first’ operator:
first(outputs(‘List_rows_Top_1_Account_with_conditions’)?[‘body/value’])?[’emailaddress1′]
In this way you avoid that the Cloud flow gets bigger and bigger and keep it clean when possible.