Tracked under Microsoft 365 AI at Work Roadmap ID 576750 and detailed in Microsoft’s 2026 release wave documentation, Microsoft is overhauling that architecture with a feature titled Power Pages: Design studio - Unify Power Pages authorization by merging web role with Dataverse security role (documented in Microsoft Learn as Enhanced Authorization). Rather than forcing Power Pages to reconstruct permissions in the middle tier on every request, the update projects site users, web roles, and table permissions directly into native Dataverse security constructs.
Having entered public preview on July 8, 2026, with general availability targeted for November 2026 across Worldwide Standard Multi-Tenant cloud instances, this change carries substantial implications for performance, compliance auditing, and custom plugin behavior. Because Microsoft’s release-plan documentation notes that its roadmap pages were archived in October 2026 and that preview timelines remain subject to change, administrators should treat the November 2026 target as Microsoft's published plan while testing the preview carefully in non-production environments.
Why the Legacy Portal Security Model Needed an Overhaul
To understand why this update matters, consider how the standard Power Pages authorization model operates. When an external user signs into a Power Pages website to view a list of support cases or submit a form, Dataverse does not natively know who that external Contact is in terms of platform-level security roles.
Instead, as Microsoft Learn’s prerelease documentation explains, Power Pages retrieves data from Dataverse using a single, elevated-privilege Power Pages application user (often referred to as the Portal App User) and evaluates table and record permissions after retrieval.
This design introduces two recurring headaches for enterprise IT and Power Platform architects:
- Performance Overhead: Evaluating complex relationship-based permissions (such as verifying whether a Contact belongs to an Account that owns a parent case) in the Power Pages runtime can require multiple roundtrips between the portal layer and Dataverse.
- Opaque Auditing and Traceability: Because requests execute under the elevated Portal App User context, native Dataverse audit logs attribute record creations, updates, and deletions to the generic application user rather than the specific external visitor who triggered the change.
With Enhanced Authorization enabled, enforcement moves directly to the data boundary. Power Pages impersonates a mapped Dataverse System User identity for that specific external visitor, and Dataverse evaluates permissions natively before returning only the records the user is authorized to see.
Under the Hood: How Identity, Role, and Permission Mapping Works
A natural question for seasoned Power Platform makers is whether they have to abandon the familiar Power Pages Design Studio security workspace and start managing external visitors inside the Power Platform admin center. According to Microsoft Learn and a deep-dive technical post on the Power Platform Developer Blog by Principal Software Engineer Gokul Narayanan, the answer is no: the maker-facing configuration stays the same, while an automated mapping layer translates those concepts into Dataverse.
| Power Pages Construct | Mapped Dataverse Construct | Underlying Storage / Technical Identifier |
|---|---|---|
| Site User (Contact) | System User (C2 User) | Mapped per website in the PowerPagesUserMapping table; marked as C2 User in the User table's System Managed User Type column. |
| Web Role | Security Role | Association stored in adx_webrole for the Standard Data Model (SDM) or powerpagecomponent for the Enhanced Data Model (EDM). |
| Table Permission | Privileges with Record Filters | Translates Global, Contact, Account, Parent, and the new FetchXML-based Custom Scope into Dataverse privileges. |
| Anonymous Visitor | Mapped Anonymous System User | Bound per website to the Dataverse Security Role mapped from the site's Anonymous Web Role. |
1. Contact-to-System-User Mapping (C2 User)
Every authenticated Power Pages visitor continues to be represented by a record in the Dataverse Contact table. When Enhanced Authorization is active, Power Pages associates that Contact with a corresponding record in the Dataverse System User table. In the User table, the System Managed User Type column identifies these accounts as C2 User.
Crucially, as Narayanan notes on the Power Platform Developer Blog, this mapping is site-aware and stored in the PowerPagesUserMapping table. Because a single person (Contact) might access two different Power Pages websites hosted in the same Dataverse environment with completely different permissions, Dataverse can create multiple System User representations for a single Contact—one per site.
What about licensing? Microsoft Learn explicitly confirms that these internally managed System Users do not grant direct internal access to Dataverse and do not require additional Dynamics 365 or Power Apps user licenses. External access continues to be governed strictly by standard Power Pages licensing. Even unauthenticated traffic follows the same path: each website receives a mapped anonymous System User linked to the security role associated with the site's Anonymous web role.
2. Web Roles to Dataverse Security Roles
Makers continue to assign access through Power Pages Web Roles. Behind the scenes, each Web Role is paired with a Dataverse Security Role. For sites running on the Standard Data Model (SDM), this link is tracked in the adx_webrole table; for sites on the Enhanced Data Model (EDM), it resides in the powerpagecomponent table. When a Contact receives one or more Web Roles, the corresponding Dataverse Security Roles are automatically applied to their site-specific System User record.
3. Table Permissions and the New FetchXML "Custom Scope"
Instead of reconstructing table permissions in the portal runtime, Power Pages translates Global, Contact, Account, and Parent scopes into native Dataverse role privileges backed by record filters for each operation.
Even better for developers who have hit a wall with rigid relationship requirements, opting into Enhanced Authorization unlocks a new Custom Scope for table permissions. Previously, if you had a standalone table in Dataverse—such as an Event table with no lookup relationship to the Contact or Account tables—you could typically only grant Global scope permissions across user tiers. With Custom Scope, makers can define granular, record-level conditions using FetchXML filters.
For example, a portal can store Free, Standard, and Premium events in a single unrelated Event table and use FetchXML record filters so anonymous visitors only query Free events, standard members see Standard events, and premium members see Premium events—all enforced directly by Dataverse at query time.
Section Summary: Enhanced Authorization preserves the maker experience in Power Pages while projecting Contacts into site-specific C2 User System Users, Web Roles into Security Roles, and Table Permissions into Dataverse record filters, adding support for FetchXML-based Custom Scopes.
The Catch: Migration Realities, Plugins, and Column Security
While Microsoft’s high-level roadmap summary states "No Migration Required" and "No changes required for makers," digging into the official Microsoft Learn preview documentation and the Power Platform Developer Blog reveals several critical technical nuances that administrators must test before flipping the switch in production.
Opt-In Translation vs. Zero-Touch Sync
There is an important distinction between day-to-day synchronization and initial enablement. Once the feature is running, creating or updating Contacts, Web Roles, and Table Permissions automatically syncs with Dataverse's System User and Security Role tables. However, when an administrator first opts an existing site into Enhanced Authorization, Power Pages runs a migration process to translate existing web roles and table permissions into the new mapped model, and the feature only activates once that migration succeeds. Furthermore, existing Contacts are mapped to their corresponding System User records when they sign in to the site for the first time after enablement.
Breaking Changes for Custom Dataverse Plugins
If your environment relies on custom C# Dataverse plugins triggered by portal activity, pay close attention. Under the legacy model, plugins triggered via Power Pages executed under the context of the elevated Portal App User, which typically possessed broad read/write privileges across the environment.
With Enhanced Authorization, Dataverse operations execute via impersonation on behalf of the site user's mapped System User. Consequently, any registered plugin runs in the calling user's context by default. If a plugin attempts to query or update background tables that the external user's Web Role does not explicitly grant access to, the plugin will fail with a privilege error. To prevent broken workflows, developers must review their plugin registrations and explicitly set the plugin step’s Run As configuration to execute under the Portal App User or another privileged service account where elevated background execution is required.
Column-Level Security Shifts to Dataverse Profiles
Administrators who use column-level permissions for the Power Pages Web API also face a behavior change. According to Microsoft Learn, Web API column-level permissions configured inside Power Pages are bypassed when Enhanced Authorization is enabled. Instead, Power Pages relies directly on native Dataverse Column Security Profiles. Secured Dataverse fields are locked down by default in Power Pages, and granting read, write, or create access requires adding the external visitor's mapped System User to the appropriate Dataverse Column Security Profile.
Section Summary: While ongoing role and user management is automated, enabling Enhanced Authorization requires an initial configuration translation and changes runtime behavior: plugins now execute under the restricted external user's context unless reconfigured via "Run As," and Web API column permissions defer to Dataverse Column Security Profiles.
Step-by-Step: How to Enable Enhanced Authorization in Preview
If you want to evaluate Enhanced Authorization in a sandbox or trial environment ahead of its planned November 2026 general availability, Microsoft Learn specifies strict prerequisite solution versions.
Prerequisites
Verify in the Power Platform Admin Center that your target environment meets or exceeds both minimum platform solution versions:
- Power Pages Core: version
1.1.2605.258or later - Dataverse Base Portal: version
9.3.2605.265or later
(If your environment runs older builds, update your Power Pages platform solutions before proceeding.)
Enablement Procedure
- Sign in to Power Pages and select the target non-production environment in the top-right environment picker.
- Locate your website in the active sites list, select the ellipsis (
...) menu next to the site name, and choose Admin center from the drop-down menu. - Inside the Power Pages Admin center, locate the site details panel and select Edit.
- Check the Enable Enhanced Authorization box and click Save.
Once saved and the initial translation finishes, test your site with both anonymous sessions and authenticated test Contacts across each Web Role, paying special attention to Dataverse audit logs, secured columns, and any synchronous or asynchronous plugins triggered by form submissions.
For those of us who have spent years explaining to compliance auditors why every single customer portal modification in Dataverse appeared to be authored by a single mysterious "Portal App User," unifying Power Pages authorization with native Dataverse security roles is a long-overdue architectural maturation. Have you started testing the C2 User mapping or the new FetchXML Custom Scope in your sandbox environments yet, or are your custom plugins keeping you cautious? Share your testing notes in the WindowsForum.com Power Platform and Enterprise IT discussions below.