Dataverse Connector's "Return Full Metadata" Parameter in Power Automate

I stumbled across something interesting today whilst working on a Power Automate cloud flow. There's this "Return Full Metadata" parameter (with key in the code view x-ms-odata-metadata-full) in the Dataverse connector that I'd never really paid attention to before. The official documentation describes it as "The header parameter to customer to opt-in returning full odata metadata in response."

Not exactly the most enlightening explanation, is it? It doesn't tell you what kind of OData metadata we're talking about, and more importantly, it doesn't explain how this parameter actually behaves.


What the Documentation Doesn't Tell You

So naturally, I did what any curious developer would do - I set the parameter to "Yes" and ran the flow to see what would happen. The result? The output JSON looked exactly the same as before.

This got me thinking. After a bit more experimentation, I discovered the real story behind this parameter:

The default value is actually "Yes" - even when you don't specify the parameter at all. The documentation completely fails to mention this crucial detail. If you want to see the difference, you need to set the parameter to "No" to get a slimmer version of the output JSON.

The Real Impact: What You're Actually Getting

When you set "Return Full Metadata" to "No", you'll notice that several OData properties are stripped out from the response:

  • @odata.type
  • @odata.id
  • @odata.editLink
  • @odata.associationLink
  • @odata.navigationLink

The good news? All the useful metadata that you actually need for business scenarios remains intact:

  • @OData.Community.Display.V1.FormattedValue (for displaying formatted values like option set labels and lookup name text)
  • @Microsoft.Dynamics.CRM.lookuplogicalname (for identifying the logical name of lookup targets especially for polymorphic lookups)
  • @odata.nextLink (for paging to retrieve the next page of results when the response exceeds the page size limit)
  • All your actual data fields

The Performance Question

Let's be honest - when was the last time you needed to know the @odata.editLink in your business logic? For 99% of use cases, you're interested in the actual data and maybe some formatting information, not the internal OData plumbing.

Whilst I haven't done extensive performance testing, common sense suggests that smaller JSON payloads should result in:

  • Faster network transfer
  • Reduced memory usage
  • Quicker JSON parsing
  • Better overall flow performance

This is particularly relevant when you're working with large datasets or when your flows are running frequently.

My Recommendation

I believe the default value for "Return Full Metadata" parameter (when not specified) should be "No" rather than "Yes" but I guess Microsoft did not wait to break the existing flows. Most developers don't need the full OData metadata for their business logic, and when they do, they can explicitly opt-in.

For your flows, I'd suggest:

  1. Set "Return Full Metadata" to "No" for all your standard data retrieval operations
  2. Only set it to "Yes" when you specifically need the OData navigation properties
  3. Test your existing flows to see if they actually depend on any of the metadata properties that get stripped out

A Word of Caution

Before you rush off to change all your existing flows, make sure you're not inadvertently using any of the metadata properties that get removed. It's unlikely, but worth checking if you have any complex flows that manipulate the raw JSON output.

Final Thoughts

This is yet another example of why it's worth digging into the technical details rather than just accepting the surface-level documentation. The "Return Full Metadata" parameter is a simple but effective way to optimise your Dataverse connector calls, but you'd never know it from reading the official docs.

Have you encountered this parameter before, or have you noticed any performance improvements after setting it to "No"? I'd be curious to hear about your experiences in the comments below.

Comments

Popular Posts