Dynamics 365 Apps
From the field archive · Learned in 2020
Portals Lessons That Still Apply to Power Pages: Authentication, Caching and Knowledge Articles
The product has a new name and a new studio. The questions customers ask about sign-in, stale data and self-service content are the same ones I answered in 2020.
In 2020 I spent a lot of time with a large automaker's HR team on an employee self-service portal built on what was then Power Apps portals. Most weekly calls came back to three topics: sign-in, changes that didn't show up right away, and publishing knowledge content. Power Pages customers ask me the same three questions today, so here's what I learned then, updated for how the product works now.
Power Apps portals became Power Pages, a standalone Power Platform product (preview in May 2022, generally available in October 2022). Identity providers are now configured in the design studio under Security > Identity providers, and Microsoft Entra External ID is a documented option alongside OpenID Connect, SAML 2.0 and WS-Federation providers. Server-side caching is now well documented, including how the data cache refreshes. The portals Web API, secured by table permissions and column permissions, is the supported way to build client-side experiences. Site actions like restart live in the Power Platform admin center under Power Pages sites. The core model of Dataverse contacts, web roles, page permissions and table permissions hasn't changed.
01Authentication starts with the contact
A common point of confusion is where identity actually lives. In 2020, a team asked me whether they could get tokens from Dynamics 365 to sign users in to a separate, non-Microsoft site that hosted a chat experience. The honest answer was no. Dynamics 365 isn't an identity provider. It stores which external identity a contact signed in with, but it doesn't issue tokens to other applications.
That's still true in Power Pages. The site uses Dataverse contact records to represent signed-in users, and those users sign in through an identity provider. Power Pages includes built-in OAuth 2.0 providers and lets you add OpenID Connect, SAML 2.0 and WS-Federation providers. If two systems need a shared sign-in, the shared piece is the identity provider, not Dataverse.
Draw the identity flow before anyone writes code. Put the identity provider in the middle, then show Power Pages and every other site as clients of it. If a design needs Dataverse to hand out tokens, the design needs to change.
One detail catches teams during data migrations: users must have a unique email address. If two or more contacts, including deactivated ones, share the same email, those contacts can't authenticate. When I see a sudden wave of "I can't sign in" tickets after a data load, duplicate contacts are the first thing I check.
02Getting users to the right sign-in page
The automaker's portal served employees whose accounts lived in a federated directory. Users kept landing on a generic sign-in page and typing their address before being redirected, which generated confusion and helpdesk calls. The fix we discussed was Home Realm Discovery in Microsoft Entra ID.
Home Realm Discovery is how Entra ID decides which identity provider should authenticate a user. You have two documented ways to skip the extra step:
- Domain hints. The application includes a hint in the sign-in request (for OpenID Connect, a
domain_hintparameter). If the domain is federated with the tenant, Entra ID sends users straight to that identity provider's sign-in page. - An HRD policy with auto-acceleration. An admin assigns a policy to the application so federated users are forwarded automatically. Microsoft notes that a domain hint in the request overrides auto-acceleration, and warns that some auto-acceleration settings can affect guest sign-in, so test carefully.
Token lifetime came up too. People wanted sessions to last a full shift without re-prompting, and security wanted shorter sessions. I'd temper expectations here: how long a session lasts depends on your identity provider's token and session policies as well as the site's own authentication settings. Agree on the policy with your identity team first, then check current docs for the matching site settings.
For the automaker, the request was simply "stop making employees pick their account." Before building anything custom, we walked through the identity provider's own Home Realm Discovery options. The best fix is usually a configuration change in the identity provider, not code on the site.
03Caching: why changes "take a while"
This was the question I answered most often. A business user changes a record in Dynamics 365, refreshes the portal, and nothing changes. It feels like a bug, but it's how the platform scales.
Power Pages caches data it reads from Dataverse on the server. Microsoft documents two categories:
| Category | What it covers | How it refreshes |
|---|---|---|
| Configuration tables | Web pages, web templates, content snippets, site settings and similar site metadata | Through change notifications, which are set correctly by default and shouldn't be changed |
| Data tables | Business data shown on the site, cached only for what users actually access, usually per user | Cleared immediately for a table when a site user creates, updates or deletes a record there; otherwise cleared automatically within 15 minutes |
The key point: a change made on the site clears the cache right away, while a change made in Dynamics 365 can take up to the refresh window. Manual cache clears should be rare, because they can slow a busy site.
In 2021 the same customer built a page where employees subscribed to apps, and the subscription controlled which app tiles appeared. Records were created instantly, but the tiles were driven by site configuration, so they lagged by up to 15 minutes. I tested it in my own environment and then asked colleagues to validate my reasoning. We gave the team two options: move the show/hide logic to the client, reading the subscription records directly, or keep the design and tell users their change could take a few minutes. Forcing the cache to refresh in code was not on the list.
Today the client-side option is the portals Web API. It supports create, read, update and delete on Dataverse tables from your pages, and it follows the table permissions and column permissions assigned through web roles. Microsoft is clear that it's built for rich in-page experiences, not for third-party integration.
Before you build, ask one question about every dynamic element on a page: is it driven by site configuration or by business data? If users expect it to change instantly after an action in Dynamics 365, don't drive it from configuration.
04Knowledge articles and web files
The HR team wanted to publish policies and how-to guides. Their first instinct was to upload Word documents as web files and link them from pages. I advised against making that the main pattern. Web files are fine for site assets, but in my experience using them as a document library causes performance and maintenance problems. Every document becomes site configuration, and the content team ends up depending on site makers.
What I recommended then, and still recommend, is to use the built-in knowledge management in Dynamics 365 Customer Service and surface articles on the site. Authors write and publish articles where they already work. Articles have versions, translations, review states and templates. When a document really has to stay a document, attach it to the article instead of turning it into a web file.
Author in knowledge management
Use article templates for consistent structure, and a review step before publishing.
Stay close to the built-in features
The customer chose to stay with built-in features wherever possible. Fewer custom pieces means less to retest after updates.
Web files as a document library
Hard to govern, tied to site configuration, and harder to keep fast.
Today, knowledge management is configured in the Copilot Service admin center, and authors can use Copilot to fill in article keywords and descriptions.
05Restricting pages and data
"We need to restrict this page" usually hides two separate requirements, and it's worth separating them early:
- Page permissions decide who can see a page. You can make a page public or limit it to specific web roles.
- Table permissions decide which Dataverse records a user can read or change through lists, forms, Liquid and the Web API. Power Pages restricts access by default, so nothing appears until you grant it.
Hiding a page doesn't protect the data behind it, so I always review table permissions first, especially Global ones.
06Who owns a case submitted from the site?
In 2021 the team asked why cases created from the portal weren't owned by the contact who submitted them. The answer is that a contact isn't a Dynamics 365 user, so it can't own a record. The case is linked to the contact as the customer, and ownership follows your organization's rules.
At the time I suggested a flow to set ownership after the case was created, and asked the team to look at routing rules and security so cases reached the right queues. Today I'd start with unified routing for records, configured in the Copilot Service admin center, to route those cases to the right queue. Use a flow only for the business rules routing can't express.
07Admin access and reactive issues
Two smaller lessons came up repeatedly.
Know who can restart the site. Restarting is in the admin center under Power Pages sites. Microsoft's roles article lists who can do it, including website owners, system administrators and Power Platform administrators. The admin role must be assigned directly, not through a security group or PIM. Sort this out before go-live, not during an incident.
Open a support case early for production issues. When a group of users suddenly saw identity errors on sign-in, the team's first fix was deleting affected users and having them sign in again. That's a symptom fix. First ask when it started, how many users are affected, what changed, and whether a support case is open.
082020 vs today at a glance
| Topic | How I handled it in 2020 | What I'd do today |
|---|---|---|
| Shared sign-in across sites | Explained Dynamics 365 isn't an identity provider | Same answer. Center the design on Entra ID or Entra External ID |
| Federated users | Home Realm Discovery settings | Domain hints or an HRD policy, tested with guest users |
| Stale data on pages | Client-side logic or a user notice | Portals Web API with table and column permissions |
| Self-service content | Built-in knowledge articles, not web files | Same, plus article templates and Copilot-assisted authoring |
| Case ownership | Flow after create | Unified routing for records, then flows for edge cases |
| Site restart | Confirm admin roles | Admin center site actions, with roles assigned directly |
Sites like these also need the same platform foundations as anything else you build. If you haven't settled environments and data policies, start with Environment Strategy and DLP: What I Recommend, and for ongoing visibility see the 2026 governance toolbox.
Where I'd start
If you're inheriting an older portal or building a new Power Pages site, I'd do three things first. Map the identity flow and remove any design that expects Dataverse to issue tokens. Label every dynamic element as configuration-driven or data-driven, and move anything that must be instant to the Web API. And publish self-service content through knowledge management instead of web files. Those three decisions prevented most of the escalations I saw in 2020.
Happy to go deeper on any of this.
— K.G
Sources
- Microsoft Learn: Overview of authentication in Power Pages; Set up site authentication; Set up Microsoft Entra External ID with Power Pages
- Microsoft Learn: Home Realm Discovery for an application; Configure sign-in auto-acceleration
- Microsoft Learn: How server-side caching works in Power Pages
- Microsoft Learn: Portals Web API overview; Set table permissions in Power Pages; Set column permissions
- Microsoft Learn: Configure knowledge management; Create templates for knowledge articles; Create and manage knowledge articles
- Microsoft Learn: Set up unified routing for records
- Microsoft Learn: Use the admin center; Roles required for website administration
- Microsoft Power Platform Blog: Announcing the preview of Microsoft Power Pages (May 2022); Microsoft Power Pages is now generally available (October 2022)
Get new posts by email
Provider: your email provider
