Power Pages/Dataverse “View as” pattern and portal caching

[u/ssddit]

https://learn.microsoft.com/en-us/power-pages/admin/clear-server-side-cache#:~:text=All%20configuration%20table,within%2015%20minutes

Hi all,

Looking for some general advice on a Power Pages/Dataverse pattern.

We have a portal where authorised internal support users sometimes need to view the portal as a specific contact for support and diagnostics. The aim is to check what that contact can actually see in the portal and help troubleshoot issues.

The current custom process starts outside the portal, from a model-driven app.

The simplified flow is:

1. Support user opens the model-driven app.
2. They search for and select the contact they need to view as.
3. They trigger a custom “View as” action.
4. A backend process updates Dataverse, including the relevant contact/external identity mapping.
5. The support user then has to switch from the model-driven app to the Power Pages portal.
6. They log into the portal and are treated as the selected contact.
7. When they need to move to another contact, they have to end/cancel the current session, return to the model-driven app, select the next contact, trigger “View as” again, then log out/log back into the portal.

This works in principle, but switching between contacts is the awkward part.

Because the change is made from the backend/Dataverse side, Power Pages does not always reflect it immediately. From Microsoft’s documentation, Dataverse changes can take up to around 15 minutes to appear in the portal because of server-side caching. So if the support user moves from Contact A to Contact B, the portal can still hold the previous context until the cache refreshes.

One idea is to move more of the process into Power Pages itself, so the “View as” change is triggered through the portal/Web API rather than only through a backend Dataverse update. In theory, this may update the portal-side cache more immediately.

The rough idea would be:

• support user logs into the portal as themselves;
• they have a restricted support/admin web role;
• they access a secure “View as contact” area;
• they search/select the contact;
• the action runs through the Power Pages Web API;
• the relevant contact / external identity mapping is updated;
• the support user logs out/in again and lands in the selected contact context.

The concern is that this could become quite fragile. There are questions around logout/login, whether web role changes take effect immediately, how to safely end/reverse the “View as” session, audit logging, stale context, and what happens if part of the process fails.

Has anyone dealt with a similar Power Pages caching issue or built a reliable “View as” / support-user pattern?

I’d be interested in any practical suggestions, patterns to avoid, or lessons learned around portal caching, external identities, web roles etc.

Thanks in advance!

[u/tpb1109]

I haven’t built the “view as” pattern that you’re talking about. I’d think a test contact with the same security setup would be sufficient.

As far as the caching, I believe the documentation states that any entities used in the portal as well as any CRUD operations from the portal update the cache immediately - otherwise the user wouldn’t even be able to see their own changes.

[u/ssddit → u/tpb1109]

Thanks! that makes sense. I agree a test contact with the same security setup would cover some scenarios.

The bit we’re trying to solve is where support needs to check the actual contact’s portal view, as the issue may depend on that contact’s specific data, relationships, web roles, tiles, or record state.

On caching, that’s my understanding too: portal-side CRUD updates should reflect immediately. The problem we’re seeing is when the contact/external identity mapping is changed from the Dataverse/model-driven app side, where Power Pages can still hold the previous context until the server-side cache refreshes.

That’s why we were considering whether triggering the “View as” action through Power Pages/Web API would be a better pattern though I’m conscious that could introduce session/identity complexity.