ecLearn - Learning Management System built on top of Microsoft Dataverse for Power Platform and Dynamics 365 users


Power Apps Portals: fetchxml Liquid Tag and Entity Permissions

The fetchxml Liquid tag is arguably the most powerful Liquid tag in Power Apps Portals – it allows you to meet complex requirements for the display of data. But, if you combine it with a complex Entity Permissions model, you could find yourself getting unexpected errors. In this post I’ll cover what can cause those errors, and how to work around them.

The Situation

Let’s assume you’ve got Entity A which is related to Contact (Contact 1:N Entity A). Then you have Entity B, which is related to Entity A (Entity A 1:N Entity B).

To expose these entities on the Portal, you can create Entity Permissions, with a Contact-scoped Entity Permission on Entity A, and a Parent-Scoped Entity Permission on Entity B. If you use functionality like Entity List and Entity Forms, this should work just fine.

However, if you want to use the fetchxml tag to query data in Entity B, and include filtering based on Entity A using a link-entity, you’ll run into problems. Here is an example of a FetchXML query:

{% fetchxml myquery %}
  <fetch aggregate="true" >​
    <entity name="ec_entityb" >​
      <attribute name="ec_number" alias="numbersum" aggregate="sum" />​
      <filter type="or" >​
        <condition entityname="ec_entitya" attribute="ec_filtertest" operator="eq" value="894820000" />​
        <condition entityname="ec_entitya" attribute="ec_filtertest" operator="eq" value="894820001" />​
      <link-entity name="ec_entitya" from="ec_entityaid" to="ec_entityaid" />​
{% endfetchxml %}

Which will produce the following error:

Liquid error: Exception has been thrown by the target of an invocation.

The FetchXML is valid – it works in the FetchXML Builder in XrmToolBox. So why doesn’t it work on Power Apps Portals?

The Application of Entity Permissions

In order to make the query as efficient as possible, the Portals code adds to your FetchXML the necessary filters to enforce Entity Permissions. This is as opposed to running the full query, and then performing the security trimming on the results.

The problem in this case is there is a conflict between our FetchXML, and the additional FetchXML added to enforce Entity Permissions.

The good news is, it is possible to look at the complete FetchXML that is sent to the CDS server, including both your FetchXML, and what has been added to enforce Entity Permissions. You can do that by accessing the .xml attribute of your fetchxml object, like so (the code also HTML encodes using the h filter so that it can be displayed on the page):

{{ myquery.xml | h }}

Which yields the following result:

<fetch mapping="logical" aggregate="true">
  <entity name="ec_entityb">
    <attribute name="ec_number" alias="numbersum" aggregate="sum" />
    <filter type="or">
      <condition entityname="ec_entitya" attribute="ec_filtertest" operator="eq" value="894820000" />
      <condition entityname="ec_entitya" attribute="ec_filtertest" operator="eq" value="894820001" />
    <filter type="and">
      <filter type="or" hint="union">
        <condition entityname="generated_alias_ec_entitya_1" attribute="ec_contact" operator="eq" value="aedf70f8-5520-ea11-a811-000d3af421db" />
    <link-entity name="ec_entitya" from="ec_entityaid" to="ec_entityaid" />
    <link-entity name="ec_entitya" from="ec_entityaid" to="ec_entityaid" alias="generated_alias_ec_entitya_1" link-type="outer" />

There you can see that the Portals code is adding another link-entity, which causes confusion with the existing one. You’ll also notice the additional filter, which filters based on a contact with an id of aedf70f8-5520-ea11-a811-000d3af421db, the ID of the currently logged in contact.

The Fix

The error is occurring because the conditions in the original FetchXML query are ambiguous – they refer to Entity A, but there are two possible links to Entity A. To remove the ambiguity, you’ve got two options:

  1. Add your own alias to the your link-entity and your filter.
  2. Once you’ve used the .xml attribute to view the auto-generated alias, remove you own link-entity and use the auto-generated alias in your conditions.

I prefer the first option. The alias that is automatically generated could in theory change at any point, breaking your code. Create your own alias just to be safe. Something like:

{% fetchxml myquery %}
  <fetch aggregate="true" >​
    <entity name="ec_entityb" >​
      <attribute name="ec_number" alias="numbersum" aggregate="sum" />​
      <filter type="or" >​
        <condition entityname="myalias" attribute="ec_filtertest" operator="eq" value="894820000" />​
        <condition entityname="myalias" attribute="ec_filtertest" operator="eq" value="894820001" />​
      <link-entity name="ec_entitya" from="ec_entityaid" to="ec_entityaid" alias="myalias" />​
{% endfetchxml %}

And with that small change, the query works as expected.

Undocumented fetchxml Tag

Despite being a powerful and popular tag, unfortunately there is no documentation for the fetchxml Liquid tag in the Power Apps Portals documentation. I’ve been told it’s on Microsoft’s list of things to do. If you’re interested, here is a summary of the available options:

{% fetchxml query %}
  <fetch version="1.0" mapping="logical">
    <!-- Write FetchXML here, use Liquid in here if you want, to build XML dynamically. -->
{% endfetchxml %}
{{ query.xml | escape }}
{{ query.results.total_record_count }}
{{ query.results.more_records }}
{{ query.results.paging_cookie | escape }}
{% for result in query.results.entities %}
  {{ | escape }}
{% endfor %}

11 responses to “Power Apps Portals: fetchxml Liquid Tag and Entity Permissions”

  1. […] post Power Apps Portals: fetchxml Liquid Tag and Entity Permissions appeared first on Engineered […]

  2. Sandip Patil says:

    Can we work with SharePoint list as a data source with liquid template language in PowerApps portal ?

    • Nicholas Hayduk says:

      Unfortunately not – the only source for Liquid is CDS. Unless I guess you somehow hook up your SharePoint list to CDS as a virtual entity.


  3. liuqin says:

    Hi Experts,

    I used the fetch xml to generate a view (joining three entities), which can be the data source of power apps control directly.

    The view would display the correct result in the view designer, but the three columns (Product, Site and Warehouse) from sub entities will be removed in the power apps and then we cannot use them. Do I miss any setup or configuration to publish the view to the CDS env?


  4. Phil says:

    if you’ve been getting – 1 from total_records_count you can use fetchxmlObject.results.entities.size

  5. Sam says:

    Thanks Nick, this article was super helpful for integrating some FetchXML queries on our portal. Just in case anyone else happens to run into the same problem; the code editor on the Content Page in our portal management app seems to ignore the /> combination at the end of Fetch attribute tags. I was finding it was ignoring everything in the query past that, so copying and pasting the output from Advanced Find doesn’t work properly. The fix in my case was to add a whole closing attribute tag after each one. i.e.:


    My query worked fine after that. Not sure if I missed something obvious but hope it helps someone else either way.

  6. CC says:

    Is the query result object documented anywhere?

  7. Keshava says:


    How to fetch current login user email, phone number, first name using liquid code in power pages?

    • Nicholas Hayduk says:

      All of the details of the current user can be retrieved using the user object. This object is the Contact row in Dataverse, so you can access any of the columns using the logical name, like:

      {{ user.telephone1 }}
      {{ user.emailaddress1 }}
      {{ user.firstname }}


Leave a Reply

Your email address will not be published. Required fields are marked *


Engineered Code is a web application development firm and Microsoft Partner specializing in web portals backed by Dynamics 365 & Power Platform. Led by a professional engineer, our team of technology experts are based in Regina, Saskatchewan, Canada.