Working with the PowerApps Portal Cache

In this note	Today
PowerApps Portals	Power Pages
CDS (Common Data Service)	Dataverse
Entity	Table
Entity Form	Basic form
Entity List	List

Overview

The purpose of this page is to provide insight into working with the PowerApps Portal Cache. Sometimes it may seem like your changes just aren’t going through, and you’re unsure whether the cause is bad changes or the Portal not updating. Other times, you might find that you’re updating data in the back-end and not seeing the changes reflected immediately, or you’re seeing some odd behavior with views. All of this is related to the Portal’s cache, which is essentially temporary storage of data that the Portal uses to reduce calls to CDS. This helps improve performance within CDS/Dynamics by not constantly processing redundant calls, as well as decrease the time it takes for data to show in the Portal.

How to Reset the Cache

To reset the cache, navigate to your Portal’s /_services/about page (e.g., https://contoso.powerappsportals.com/_services/about) while logged in as a Contact with the Administrator Web Role. If the logged-in user does not have the appropriate role, or the user is not authenticated, they will see a nearly blank page. However, if the role is present, they should see something like the page below. From here, you want to click the Clear cache button, which will force any pending changes to cascade. Performance will be impacted briefly, but not as badly as with a full Portal Reset.

Figure 1Admin page

Callout 1: Only visible to a signed-in Contact with the Administrator Web Role.
Callout 2: Clear cache forces pending changes through without a full portal restart.

Recreated illustration. The original screenshot was lost with the old site; this drawing follows the article text.

Understanding the Cache

The cache is a means to reduce redundant queries to CDS. This means that any new query will make a request to CDS, but reused queries will not. Let’s say you have a list of Accounts that shows the fields “Account Name”, “Primary Contact” and a custom “Last Portal Updated On” DateTime field. When a user opens a record from the list and updates it, it triggers a Power Automate process to asynchronously update multiple fields, and then updates the DateTime field with the current time. After the user makes a change and submits it, they are taken back to the listed view of Accounts, but for some reason the “Last Portal Updated On” is unchanged, even though they’ve just updated the Account. Now, say they click on one of the grid columns to change the sort order – this is a new query, and suddenly the “Last Portal Updated On” is showing the new date! So they change the sort order back and… it’s showing the old date again?

Each of the sort changes is a new Fetch query, and the query results are stored against that particular query. Depending on when the cache last updated, and when you last attempted a different sort, you can see different data for every possible sort on the exact same record.

Limiting Cache Issues

There are certain steps you can take that will limit the impact of cache issues. Here are some tips:

Enable Change Tracking for all Entities that you want to show updates in the Portal
Limit the work of asynchronous processes on Portal-visible data – if possible, use synchronous code or Portal-originating updates (JavaScript to update ‘hidden’ fields, Entity Form Metadata, etc.)
Read up on how to use the {% substitution %} tag in the Header and Footer Web Templates

Bypassing the Cache

While you can’t actually bypass the cache, there is a common trick you can use in some rare places: make every query unique. The simplest way to do this is to add something random or generated to each query, most commonly the JavaScript Date.now(). This passes a number representing the current date and time, down to the millisecond. Note that this essentially means you must be able to use JavaScript in your Liquid code, which is not possible unless the Liquid code is retrieved from JavaScript. The most common way to do this is to use a Web Page as an API Endpoint, which I will be posting about shortly.

Liquid tags embedded directly in Web Templates can still fall victim to the cache. In some of my older findings, for example, the {{ now }} tag showed the time of the user’s login rather than the actual current time. Additionally, there isn’t really a way to plant randomization into System Views for your Entity Lists, and sometimes even the data directly on an Entity Form can be affected by cache issues, though I haven’t seen the latter occur in a while.

Wrapping Up

Those are all of the tips and tricks I can think of for now. Be sure to check out some of my other posts, or the Code Snippets page, if you’re curious for more.