How I Eliminated Power Pages Caching
How I Eliminated Power Pages Caching Issues Using the Dataverse Web API
f you’ve ever built a portal using Power Pages, chances are you’ve hit one of the most frustrating issues:
You create a record, save it successfully… and it doesn’t appear in your list — even after refreshing the page.
This is exactly what happened to me while building a Call-Off submission and tracking feature integrated with Business Central using Dataverse.
In this article, I’ll show you:
Why this caching problem happens
Why Liquid
{% fetchxml %}is often the root causeAnd how I fixed everything using the Dataverse Web API for real-time updates
This solution is now running in production with instant updates and zero caching delays.
The Original Architecture (And Why It Failed)
My original setup looked like this:
Sales Orders synced from Business Central to Dataverse
Call-Off records stored in Dataverse
Power Pages displaying Call-Offs using Liquid FetchXML
JavaScript used to “refresh” the table after form submission
On paper, this sounds fine. In reality:
Newly submitted Call-Offs did not show up
Even manual page refreshes sometimes still showed old data
On the second submission, both records would suddenly appear
Users assumed their first submission had failed
The Root Cause: Liquid Is Cached
Liquid output in Power Pages is server-side rendered and cached. This means:
{% fetchxml %}does not guarantee real-time dataSubmitting an Entity Form does not invalidate that cache
Even custom JSON endpoints built with Liquid can return stale results
This makes Liquid a poor choice for frequently changing transactional data.
The Real Fix: Switch to the Dataverse Web API
Instead of fighting the caching layer, I completely bypassed it.
All Call-Off retrieval now happens using:
The Dataverse Web API
Client-side JavaScript
webapi.safeAjaxfor secure authenticated calls
This delivers:
True real-time data
No caching
Instant visual updates
Full control over filtering and rendering
Step 1: Query Call-Offs Using the Dataverse Web API
Here is the exact pattern I now use in Power Pages:
function loadCallOffs(salesOrderNumber) {
webapi.safeAjax({
type: "GET",
url: "/_api/plh_calloffs?$select=plh_name,plh_quantity,createdon" +
"&$filter=plh_salesordernumber eq '" + salesOrderNumber + "'" +
"&$orderby=createdon desc",
contentType: "application/json",
success: function (res) {
let rows = "";
res.value.forEach(r => {
rows += `
<tr>
<td>${r.plh_name}</td>
<td>${r.plh_quantity}</td>
<td>${new Date(r.createdon).toLocaleString()}</td>
</tr>
`;
});
document.getElementById("calloffTableBody").innerHTML = rows;
}
});
}
Why This Works
It talks directly to Dataverse
Uses live OData queries
Completely bypasses Liquid and its caching layer
Step 2: Instantly Reload After Form Submission
Once the Call-Off Entity Form saves successfully, this event fires:
$(document).on("entityFormSaved", function () {
loadCallOffs(currentSalesOrderNumber);
});
The New User Flow:
User submits a Call-Off
Record is saved in Dataverse
Web API is called instantly
The table refreshes
User sees their data immediately
No page refresh
No delays
No confusion
No duplicate submissions
Final Architecture That Works Perfectly
Here’s the production-ready structure I now use:
Business Central → Dataverse (Sales Orders sync)
Dataverse → Power Pages (Call-Off storage)
Liquid used only for:
Initial Sales Order page context
Static reference data
Dataverse Web API used for:
Call-Off listing
Real-time refresh
Client-side filtering
This hybrid architecture gives you the best of both worlds:
Liquid for stability
Web API for real-time UX
Common Mistakes That Cause Caching Headaches
If you’re struggling with Power Pages refresh issues, you’re probably hitting one of these:
Using
{% fetchxml %}for frequently updated recordsExpecting Entity Forms to clear the Liquid cache
Reloading cached JSON endpoints built with Liquid
Relying purely on server-side rendering for transactional data
When Liquid Is Still the Right Choice
Liquid is still excellent for:
Page layout
Security trimming
Record lookups on initial page load
Styling and content structure
But the moment users are creating or updating records, the Dataverse Web API is the correct tool.
The Final Result
After switching to the Dataverse Web API:
Call-Offs now appear instantly
No caching delays
No refresh hacks
No “ghost submissions”
Zero support tickets since launch
It turned a fragile portal into a production-grade real-time system.
Why This Matters for Power Pages Developers
If you’re building:
Customer portals
Supplier portals
Internal Power Pages apps
Business Central-integrated solutions
Then understanding when NOT to use Liquid is just as important as knowing how to use it.
This single architectural change dramatically improved:
User trust
Data reliability
Support workload
Overall UX quality
