I’ve been struggling with portal caching lately – I would update some data in Dynamics, and that change would not be reflected on the portal right away. Unfortunately, there are times when this behavior is just not acceptable since it may lead to all kind of negative feedback from the portal users.
And, then, it seems that an ultimate solution presented itself in the form of this tip of the day:
https://crmtipoftheday.com/784/some-finesse-in-portal-cache-resets/
I am not talking about publishing all customizations or about invalidating the cache.. I’m talking about the Change Tracking option:
Enable it on the entity, publish all.. Refresh the cache as described here:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/clear-server-side-cache
Maybe refresh it twice. And, then, enjoy the results. To be fair, it seems that, occasionally, some data may still be cached “incorrectly”, at least that’s the impression I got so far. Still, in 9 out of 10 cases it seems to be working once that change is in place.
I’d really love this tip to be mentioned in the portal documentation..
I have always found caching of the portal a bit misleading. I guess internally the cache of a specific record is invalidated in an asynchronous call so it might take some time to see it happen. With the introduction of new technologies like Flow (Power Automate) I think it’s going to be harder to keep track of the cache of an entity. I wished there was a way to force cache invalidation for a record like setting up a flag or even an API call but there is nothing yet….someday!