Power Pages enhanced authorisation: what to check before you opt in
Power Pages enhanced authorisation moves table permission checks out of the site and into Dataverse, and the site starts calling Dataverse as the signed-in user. It's a good change. It also breaks things that quietly relied on the old way, so check your plugins and secured columns before you tick the box.
What actually changes
In the standard model, Power Pages reads data from Dataverse using its own application user, which runs with elevated privileges. The site then filters the results against your table permissions. Dataverse never really knows which portal user asked.
With enhanced authorisation (Microsoft spells it "authorization"), that flips:
- Dataverse does the checking. It evaluates permissions based on the site user's roles and only returns the records that user is allowed to see.
- Each contact gets a system user. Power Pages creates and manages a system user for each contact. Microsoft says these don't give direct access to Dataverse and don't need extra licences. One contact can end up with more than one if they use more than one site.
- Each web role maps to a Dataverse security role. Your table permissions get reflected in those roles, so your existing web roles keep working.
- Calls run as the site user. Dataverse operations use impersonation instead of the application user. Plugins run as the calling user unless they're set up otherwise.
- Auditing shows the real person. If auditing is on for a table, changes made through the site are recorded against the site user.
It also unlocks a new Custom access type on table permissions, where you define access with a FetchXML filter. That's only available on sites with enhanced authorisation turned on.
Enhanced authorisation is in preview. Microsoft's own guidance is that preview features aren't meant for production use. Try it in dev and test now so you know what breaks. Don't switch a live site over just because the checkbox is there.
Check 1: plugins that assume the portal is an admin
This is the one that bites. A lot of portal plugins were written knowing the calling user was the Power Pages application user, which could do pretty much anything. Once calls run as the site user, that plugin runs with whatever that user's security role allows.
Look for plugins that:
- read or update records the contact can't see on the site, like a parent account, a config table or a related case
- create records in tables the portal user has no table permission on, like audit logs, tasks, notifications or integration queue rows
- check
UserIdorInitiatingUserIdto work out whether a request came from the portal - build an
IOrganizationServicefor the calling user and expect it to have broad rights
Anything else that filters on "created by the portal app user" goes the same way: views, flows, reports, integration jobs. Records created through the site will now show the site user's system user in createdby and modifiedby.
The fix is usually one of two things. If the plugin genuinely needs to do more than the user can, run that step in a specific user's context (the Run in User's Context setting on the step) or create the service for a specific user in code. If it doesn't, give the web role the table permission it was quietly missing. Pick the second where you can. The first is fine, but be clear about why it's there.
Check 2: secured columns
Two changes here, and they pull in opposite directions.
- Power Pages column permissions stop applying. The column permission profiles you set up for the Web API are bypassed once enhanced authorisation is on. If you relied on them to hide a column from the Web API, that protection is gone.
- Dataverse column security profiles take over. These now apply to everything on the site: Web API, forms and lists. You manage the profiles in the Power Platform admin centre and assign site users to them in the Security workspace in design studio.
So list every column that has column security turned on in Dataverse and every column permission profile on the site, then work out what each type of user should see. Expect two failure modes in testing: a secured column that now comes back blank on a form that used to show it, and a column you thought was hidden in the Web API that now isn't.
Check 3: table permissions
Your table permissions are about to be enforced by Dataverse. That's a good time to find out what they really grant.
- Find every Global permission and ask whether it needs to be. Global means all records in the table.
- Check what the Anonymous Users and Authenticated Users roles can do. They apply to everyone in that group.
- Walk the parent and child permissions and make sure each child's web roles are on the parent too.
- Look for places where JavaScript or Liquid filters records "for security". Client-side filtering was never a security boundary. Dataverse will now only return what the permission allows, so pages that depended on that filtering will look different.
- Where you've been bending Contact or Account access to fit a rule, see whether the new Custom access type does it more cleanly.
Check 4: Web API calls
Anything calling /_api from the site is now asking Dataverse as the user. Go through your JavaScript and list each table and operation it calls. For each one, make sure the web role has the right privilege, and that the Web API is only turned on for the tables and columns it actually needs.
When you test, keep the browser developer tools open. A 401 or 403 from /_api usually means a permission gap. A 500 usually means a plugin failed behind it, and the plugin trace log will tell you which one.
Check 5: test in a non-prod site first
- Use a copy of production, or a test environment with realistic data and the same plugins.
- Update the Power Pages solutions. Microsoft lists minimum versions: Power Pages Core 1.1.2605.258 or later, and Dataverse Base Portal 9.3.2605.265 or later.
- Turn it on from the Power Pages admin centre: open the site's admin centre, select Edit next to the site details, tick Enable Enhanced Authorization and save.
- Sign in as a test user for each web role, plus anonymous. Not as an admin. An admin account hides exactly the problems you're looking for.
- Run every journey that writes data: registration, profile updates, each form, file uploads, anything that fires a plugin or a flow.
- Check the records afterwards. Owner, created by, related records, anything a plugin should have created.
- Write down what you changed and what you tested, so production is a repeat, not an experiment.
Microsoft's page doesn't describe switching it back off, so don't plan on doing that in production. Find the problems in test.
Not the same as the enhanced data model
People mix these up. The enhanced data model changes how the site's configuration is stored (moving from the adx_ tables to powerpagecomponent) and has its own migration through the PAC CLI. Enhanced authorisation changes how permissions are checked. They're separate settings with separate checklists, though both catch out plugins that make assumptions about the old setup.
If you'd like a hand
Reviewing table permissions, column security and the plugins behind a portal is what I do as a Power Pages developer. If you've inherited a site and don't know what it exposes, a Dynamics 365 and Power Platform health check covers it, with a written report and fix plan.
Checked against Microsoft Learn on 9 November 2026. The feature is in preview and the details may change, so check the links below before you plan around them.