This WTF episode is how to trigger your cloud flow for Dynamics 365 or Dataverse based on the Regarding object type. The trigger I refer to in this WTF episode is the When a row is added, modified or deleted trigger from the Dataverse connector.
In an activity record and some other tables such as the SharePoint Document Location table, there is a lookup field/column that goes by the name of Regarding. This field on a form allows you to select another record/row from a table that it is in regards to. For example,
- An email is associated to a Case. The case would be the value in the Regarding field.
- A document has been uploaded against the Case. Behind the scenes, a SharePoint Document Location record is created to represent the location of where the file has been uploaded to in SharePoint.
What if you need to trigger your cloud flow only when a document is uploaded against a Case and not trigger when a document is uploaded against an Account? This is what you'll learn in this WTF episode.
Anatomy of the Regarding lookup column
There are different types of lookups and as mentioned earlier, the Regarding field in a form will also you to select another record/row from a table. Refer to this blog post for more details.
In model-driven apps, you see it as "Regarding," where you select the table followed by the record/row.
If you review the attribute settings of the column you'll see there is a reference to "Target Record Type" which represents the table of the Regarding object. Below is a screenshot from the classic editor.
Underneath the hood there's two parts to the Regarding column (regardingobjectid),
- Regarding object value - this is the GUID of the record/row
- Regarding object type - this is the table of where the record/row resides in
In my earlier screenshot of the Document Location the Regarding lookup column is a row from the Case (incident) table.
Why can't I use the Filter row field in the trigger?
You can try like I did but you're going to run around in circles. You'll be asking yourself why the cloud flow does not trigger.
If you attempt to perform the filter by calling the web API directly, you're also going to find it difficult to achieve. If you search for it online using your Google powers, you'll see what I mean when you read the responses to people who have tried to filter by the Regarding object type.
If you attempt to perform the filter by calling the web API directly, you're also going to find it difficult to achieve. If you search for it online using your Google powers, you'll see what I mean when you read the responses to people who have tried to filter by the Regarding object type.
The other clue is when you review the properties returned in the API after calling it directly, you won't see a property that is in reference to the Regarding object type, only the value.
So what can you do?
One of the beautiful things about cloud flows is that we can reference any property returned in the response of a trigger or an action. This can be a blessing in disguise and in this scenario, it is.In my vlog I showed you that I had a cloud flow with the When a row is added, modified or deleted trigger and a compose action with a dummy value so that I could show you what properties are available in the response of the trigger.
Let's take a look at the run history and review the properties returned. As you can see one of the properties returned is _regardingobjectid_type
This is a property we can reference but it's not going to be in the Filter row field of the trigger. It's going to be in the old school Conditions option within the Settings of the trigger. Click on the ellipsis and select Settings.
In here you'll see the ability to add a Condition and this is where we can enter an expression that references the property.
In here you'll see the ability to add a Condition and this is where we can enter an expression that references the property.
In my second WTF episode (#throwback) I explained how to write expressions using the legacy Conditions action (note this no longer exists) where it's separated into three parts as per the screenshot below.
The first part represents the condition and in our use case we want the Regarding object type to equal the Case table.
The second part represents where the attribute (column) is being retrieved from and in our use case it will be retrieved from the Trigger.
The third part represents what value of the attribute needs to equal and in our use case it is the entitysetname of the Case table which is incidents.
The expression to use when filtering by table based on the Regarding object type is
The second part represents where the attribute (column) is being retrieved from and in our use case it will be retrieved from the Trigger.
The third part represents what value of the attribute needs to equal and in our use case it is the entitysetname of the Case table which is incidents.
The expression to use when filtering by table based on the Regarding object type is
@equals(triggerBody()?['_regardingobjectid_type'],'incidents')
That's it!
Cloud flow in action
Upload a document against the Case and the cloud flow will be triggered.
If a document is uploaded against an Account, the cloud flow will not be triggered.
Summary
By using the trigger conditions within the Settings of the trigger, you can use an expression that allows you to reference properties from the response of the trigger. This is something we can't do today in Dynamics 365 classic workflows or when you call the API directly. Thanks Power Automate!
#LetsAutomate
The truth
It took me hours when I couldn't get it working with the Filter row field and when I reviewed all the questions + responses in stackoverflow about trying directly through the Dynamics 365 API, it wasn't leading anywhere either. Then I thought - hey why not try the trigger conditions since we can call properties of the trigger. It worked and I slept peacefully that night lol 😆
If you do use this, please let me know by giving me a shout out on Twitter - @benitezhere 😊
If you do use this, please let me know by giving me a shout out on Twitter - @benitezhere 😊