Power Apps Portals: Changes to Caching

Caching has long been a hot topic when it comes to the Portals technology – so much so that it’s used in the name of top-rated Power Apps Portals podcast “Refresh the Cache” hosted by MVPs Nick Doelman and Colin Vermander. So, what is caching, why is it important for Power Apps Portals, and what’s changed about it recently?

What is Caching?

In general, caching is the idea of saving information in a place that easily/quickly accessible, as opposed to always going to the actual source. Caching is heavily used throughout the internet, for things like DNS lookups (translating human-readable domain names into computer-understandable IP addresses) and loading web pages (caching is used for items like images and JavaScript files).

One of the challenges with caching is figuring out what to do when the source changes. For example, if your computer has cached the fact that points to, but then Microsoft changes it, how does your computer know to get the updated value? In general, caching often relies on remembering information for a certain period of time, and then it will go back to the original source.

How does Power Apps Portals use Caching?

Your Power Apps Portal is hosted on a web application, that is hosted on Azure, separate from the CDS database. Querying the CDS database takes time, so rather than querying every time, the Portal application code caching the answer to those queries in memory and uses those instead of always asking.

Have you ever noticed how long the first page load takes after restarting your Portal? This is because nothing is cached. If caching wasn’t used, every page load would take that long. And nobody would use it.

The challenge with caching for Portals is when data is updated directly in CDS, without going through the Portal. In those cases, the Portal isn’t aware that anything has changed, and so has no reason not to trust the responses to the queries it has stored in its cache. So how does the Portal find out about the changes?

Back in the Day…

The process of letting the Portal know that its cache needs updating is also known as cache invalidation. We’ve gone through a few iterations now of cache invalidation techniques:

  • The original Adxstudio implementation relied on CDS plugins firing when data was created or changed. These plugins sent messages to the Portal telling it what had changed, and so the Portal knew which part of its cache to forget. The problem with this system was that for large databases, handling all of the plugin events could wreak havoc with the asynchronous service.
  • When Microsoft took over development, they started relying on the Change Tracking feature, which sends messages to Event Hub, and those messages were processed by the Portal.

Now Microsoft has moved to a slightly different model, with the biggest change being that not all entities are treated equally. For the techniques mentioned above, all entities were treated the same (as long as you configured the plugins or Change Tracking). In this new model, Microsoft has split the entities into two types: configuration and non-configuration entities.

Configuration entities are the core Portal entities like Web Page and Web Template. For a full list, see this blog post from Microsoft announcing the change. For these entities, there is no automatic invalidation of the cache – any changes to those records via the CRM API or the Portal Management Model-Driven App require you to manually clear the cache.

Any entity that is not in that list is considered a non-configuration entity, and the cache will be invalidated automatically. The official SLA for cache invalidation for these entities, as mentioned in that same blog post, is 15 minutes.

Clearing the Cache

How do you go about clearing the cache for the configuration entities? You’ve got a few options:

  1. On the _services/about page, if you are logged in as an administrator, there is a new Clear config button. This will only clear the cache for configuration entities, and is the preferred method if you’ve only made changes to configuration entities.
  2. On that same page, the Clear cache button still exists. This will clear the cache for all entities, including configuration entities.
  3. In the new Portal editor (aka the new “Maker” experience), clicking the link in the top right corner that says Browse website will cause a full cache reset like the Clear cache button does.

It’s important to note that any changes made via the legacy front-side editing, or via the new “Maker” experience shouldn’t require you to clear the config cache. It should only be necessary when making changes via the Model-Drive App, or via the CRM API (which includes tools like the Portal Code Editor for the XrmToolBox, which use the CRM API).

3 responses to “Power Apps Portals: Changes to Caching”

  1. […] post Power Apps Portals: Changes to Caching appeared first on Engineered […]

  2. […] December I blogged about the chances to caching in Power Apps Portals. While I was playing around with the new Clear config button, it didn’t work at all as I […]

  3. […] December I blogged about the chances to caching in Power Apps Portals. While I was playing around with the new Clear config button, it didn’t work at all as I […]

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.