If you’ve worked with Power Pages (or its predecessors—Dynamics 365 Portals, Power Apps Portals, or even Adxstudio Portals), you know that the security story has always had a bit of a split personality. Portal Web Roles on one side, Dataverse Security Roles on the other. In other words, two models, two sets of permissions, two audit trails. Not ideal, and certainly not easy to explain to new admins or clients. Always was fun when delivering Portal Training to clients.
I’ll be honest: after a few years away from the trenches, I’ve watched the evolution mostly from the sidelines. So when I saw Microsoft’s announcement about “unifying” Power Pages authorization, I had to do a double-take and check what was actually changing. This post is my attempt to summarize what’s coming in 2025 Wave 2 as far as Portal Security given What I know and what it means for those of us configuring or supporting Power Pages security.
What’s Actually Changing?
Here’s what Microsoft is saying, in their own words (Microsoft Release Plan):
“With this feature, the system stores each Power Pages user in the Dataverse System User table and the Contact table. The system stores each Power Pages web role in the Dataverse Security Role table and the Web Role table. You don’t need to migrate data to sync contact and web role records with the system user and security role tables. When a Power Pages user calls Dataverse, the user context of the signed-in user impersonates requests instead of the application user context.”
Here’s what that means in practice:
- Power Pages users are now represented as both Dataverse System Users and Contacts.
- Each Web Role is now mapped into the Dataverse Security Role table
- You do not need to manually migrate or sync data. The system handles this linkage.
- When a Power Pages user calls Dataverse, it’s done under that user’s context, not a generic app context.
- The assignment of roles is still done in the familiar way (Web Roles), but there is now a Dataverse Security Role for each Web Role.
Multiple MVPs and community consultants are confirming these key points. See this post by Michel Mendes and this summary by Nicholas Hayduk, both of whom work extensively with Power Pages. They reiterate that:
- Web Roles are not being eliminated. They’re now paired/mapped with Dataverse Security Roles.
- The permissions enforcement happens in Dataverse using the real user’s context.
- Administration and auditing benefit, since user actions are tracked as themselves.
What This Means for Existing Environments
Based solely on the cited documentation, here’s what you need to know:
- No immediate action is required. Microsoft handles the mapping and sync between the old and new tables—no migration projects, no data exports/imports.
- Continue using Web Roles as usual for portal assignment. You’ll simply find that each Web Role now “shows up” as a Dataverse Security Role.
- Your portal users will appear as Dataverse System Users, not just Contacts. This improves traceability and aligns with how permissions are checked when they access Dataverse data via Power Pages.
- If you have customizations or reporting built around Web Roles, you’ll want to check how those interact with the new mapping, but nothing in Microsoft’s public announcement says your existing logic will break.
As always, it’s smart to review your security setup and test key user scenarios once Wave 2 is rolled out
Why This Actually Matters (and What’s Not Changing)
The main benefit, as described in the Microsoft doc and by community voices, is unified permission enforcement and better auditing.
Web Roles are still your “assignment” primitive for portal access.
Dataverse Security Roles now mirror each Web Role and are enforced by Dataverse security checks under the real user context.
You do not need to reassign or manually convert anything.
It’s not the total elimination of Web Roles, but it’s a big leap toward making portal security understandable, auditable, and consistent with the rest of the Power Platform.
Final Thoughts
Personally, I’m glad to see Microsoft addressing this long-standing source of confusion even if the fundamentals are still familiar. It’s just the backend machinery that’s gotten smarter and more unified. I’m cautiously optimistic about where this is heading!
Citations:
- Microsoft 2025 Wave 2 Release Plan – Unify Power Pages authorization
- Michel Mendes, MVP, on LinkedIn
- Nicholas Hayduk, Portal MVP, on LinkedIn
Robert Bailey
Power Platform Solution Architect
robert-bailey.blog
Power Platform Scrum Master 
How are Microsoft then doing the mapping of “related” security through relationships for the Portal users, as the current dynamics model does not support a similar mechanism as far as I am aware.
Secondly how are Microsoft planning on matching a portal user to the system users if they are potentially the same user?
LikeLike
The short answer is there is no OOTB mapping or portal users to dynamics users at this time to my knowledge but I’ll look into it more for future installments. Portal users are always mapped to Contacts in Dataverse / CRM. Now these contact records could be custom mapped in some way to users in Dynamics, though there is no OOTB functionality that comes with such a pairing since Dynamics security roles are totally separate from web roles and entity permissions on the portal.
The confusing part of course is that single-sgn on via Entra ID is easy to achieve – just allow for entra ID on the portal and you can sign in with the same account you use to sign into dynamics. But the user record in dynamics does not map automatically to the portal user login contact, and again, there is no parity in permissions whatsoever. You could be a sys admin in dynamics and it won’t affect your portal user.
LikeLike