Some fairly basic, but useful things to know for Power Automate flows using the Dataverse connector
- ryangaming2k14
- Oct 24, 2024
- 3 min read

In my experience creating and debugging Power Automate flows with Dataverse, I've come across quite a few little annoyances and found a few small details that are or at least were at the time, not documented well by Microsoft. Most of the help I received was from online forums and blogs like this one.
I wanted to list here some of the information that isn't quite intuitive, especially for beginners when it comes to creating a flow.
OData Filters
Coming from a non-developer background, I think that anything that isn't plain or simple english, is code, or "code-y", which means for me "low-code" is code, just not "pro-code". One of the few "low-code" languages Power Automate uses is called OData. The "Open Data Protocol" is a standard data access protocol that can be used to interact with RESTful APIs for querying and updating data. Dataverse is an Odata-compliant API.
Anyway, even when you are not planning to use an OData filter expression, you are forced to use them in certain fields in triggers and actions through the Dataverse connector. To simply filter your triggering row - for example to only trigger the flow if the Status = Active, you need to use these OData filters. In that example, the answer would be "statecode eq 0". Below are list of OData filters you can use:
eq: Used for exact matches.
ne: Used for not equal to.
gt: Used for greater than.
lt: Used for less than.
ge: Used for greater than or equal to.
le: Used for less than or equal to.
and: Used to combine multiple filters with an “and” condition.
or: Used to combine multiple filters with an “or” condition.
When I first tried to learn Power Automate, this list of filters was not in Microsoft Docs and it was only found on one website. Today I have found a couple more that show it.
Debugging
It is general knowledge that you can debug each Flow run from the past 30 days, by clicking on the Flow and viewing the flow runs to see how far through the flow the run got to and the error message associated with it. In make.powerautomate.com, you can often see slightly more detailed information about the flow run error.
Lookup Field Syntax
A common "gotcha" is when a flow fails because a lookup field is wrong. This will come up with the error detailing something along the lines of: "URL Segment unrecognised".
When you populate a lookup field, you need to use the format: "EntitySetName/(Dynamic Content lookup value)". Due to Microsoft's english algorithm, you can end up with an EntitySetName for something like sshared_jobs = sshared_jobses. Additionally, the out of the box entities, such as the default entity of Units in D365 Sales, may come out as "uoms".
You can use the Metadata Browser tool in the XRMToolbox to confirm what the actual EntitySetName is for your lookup entity.
Missing Data
The other "gotcha" related to this, is when the dynamic content lookup value you're trying to use does not exist on the entity you're trying to get it from i.e., that field is blank. Power Automate will fail. The 2 ways we have got round this is either to make branching condition controls to check if it's blank, and write the same step in both Yes and No branches with and without that lookup being populated - but this gets tedious with lots of lookup fields - or the other way more often used, is within the system, enforce the user to populate or get the system to auto-populate those fields if it's blank, so that it never will be blank.
Deployment
When you deploy the Flow for the first time, remember to go to it in the new environment and sign into it again.
Oh and one more thing -
Just like workflows, Power Automate Flows won't work if the environment is in Administration mode.
Comments