Why your FetchXML fails with LIKE '%value%'
This error:
Liquid error: Exception has been thrown by the target of an invocation
is very common when using virtual tables + FetchXML + LIKE with leading wildcards.
The root cause:
Virtual tables do not support server‑side substring searches (LIKE '%value%') because the underlying provider (SharePoint in your case) cannot translate that query into its native API.
So when Power Pages sends:
<condition attribute="cr6a3_location" operator="like" value="%value%" />
Dataverse tries to push that filter down to the SharePoint virtual table provider, and the provider throws an exception — which surfaces as the Liquid error you’re seeing.
This is by design and affects all virtual tables, not just SharePoint.
Why value% works but %value% does not
SharePoint (and most virtual table providers) can translate:
This is why you get results with value% but an exception with %value%.
Why you cannot fix this with Liquid alone
Liquid runs after FetchXML executes.
If FetchXML fails, Liquid never gets a chance to run.
So you cannot do:
Because the FetchXML query itself fails before Liquid executes.
The correct workaround (supported)
1. Remove the substring filter from FetchXML
Fetch all rows you need:
<filter>
<condition attribute="cr6a3_isactive" operator="eq" value="1" />
</filter>
2. Apply substring filtering in Liquid
Liquid can do substring checks:
{% assign search = value | downcase %}
{% for row in postsQuery.results.entities %}
{% assign location = row.cr6a3_location | downcase %}
{% if location contains search %}
<!-- Render your row -->
{% endif %}
{% endfor %}
This works because Liquid filtering happens in memory, not via the virtual table provider.
Performance note
If your virtual table contains thousands of rows, client‑side filtering may be slow.
If that happens, consider:
-
Adding a “starts with” filter in FetchXML to reduce the dataset
-
Or storing a search‑friendly normalized column in SharePoint (e.g., lowercase, concatenated keywords)
Summary
-
%value% fails because virtual tables do not support contains searches.
-
value% works because starts‑with is supported.
-
The only reliable workaround is:
Fetch without substring filtering → filter using Liquid.