Microsoft tightens Power Pages security by enforcing access inside Dataverse
Reviewed by Helen Jones
Microsoft opened a public preview of Native Dataverse Authorization for Power Pages. Access checks now run inside Dataverse itself rather than only through the older portal layer. External contacts are treated as Dataverse users, web roles line up with Dataverse security roles, and operations run in the signed-in user’s context. The preview also adds column security profiles, Custom Scope rules for row-level access based on business conditions, and audit logs that show the actual external user. Makers turn the feature on per website. The studio experience for building pages stays the same, but custom plugins or logic that previously ran with elevated privileges may start failing and need retesting.
Until now, many Power Pages sites relied on a shared application identity for data access. That made external portals easier to stand up, but it blurred who really touched which rows and fields, and audit trails often looked like the system rather than the person outside the company. With native authorization, the same Dataverse security model that protects internal apps can govern external users more tightly. That is useful if your org ever shares request trackers, case forms, or partner portals on Dataverse. It does not change how a typical internal canvas app talks to a SharePoint list, and it is still preview, so early adopters must recheck custom code before flipping the switch.
Analysis
Treat this as a watch item unless you already run Power Pages against Dataverse for people outside your tenant. If you do, list any plugins or custom logic that assumed elevated rights, then test them on a non-production site with the new authorization enabled before you touch production.
Source note
Pulse published by Collab365 Spaces, reviewed by Helen Jones on . Cite as "Microsoft tightens Power Pages security by enforcing access inside Dataverse", Collab365 Spaces. 4 sources referenced.