Power Pages: Governance, DLP Policies, and Admin Configuration Guide
Why Governance Breaks Down in Power Pages
I've worked with dozens of enterprise teams who hit the same wall: they spin up a Power Pages site, it works beautifully in the sandbox, then the moment it reaches production , or the moment an admin tightens the tenant's Data Loss Prevention policies, everything falls apart. Forms stop submitting. External users get blank error pages. The site goes dark and nobody knows why.
Power Pages governance issues are uniquely painful because the platform sits at an intersection of three different control planes: the Power Platform admin center, Microsoft Dataverse environment settings, and the site's own Portals Management app. When these don't align, and they often don't out of the box, you end up chasing ghosts.
Here's the core thing to understand. Power Pages is a secure, enterprise-grade SaaS platform that runs on top of Dataverse. That means every configuration decision you make ripples across your whole Power Platform environment, not just the site. A DLP policy that blocks a connector in Power Automate can silently kill a cloud flow that your Power Pages form depends on. A table permission misconfiguration in Dataverse means your authenticated users hit a 403 and have no idea why. These aren't obvious errors, Microsoft's default error pages are notoriously unhelpful.
The most common Power Pages governance problems I see in enterprise environments break down into four buckets:
- DLP policy conflicts, A connector your Power Pages site needs (Dataverse, custom APIs, Power Automate HTTP connectors) gets moved to the "Blocked" group after a tenant-wide policy update.
- Web role misconfigurations, Users land on the site but can't see data, submit forms, or access pages that require specific roles. The role either wasn't assigned or the table permissions attached to that role are incomplete.
- Authentication provider failures, Azure AD / Entra ID configurations break after tenant changes, leaving external users stuck at a login loop or a generic "Sign-in failed" message.
- Licensing and capacity gaps, Sites go offline or degrade because authenticated user capacity runs out, or because the environment's Dataverse storage hits a ceiling nobody was watching.
I know this is frustrating, especially when your Power Pages site is customer-facing and every minute of downtime costs you credibility. The good news is that every single one of these problems has a specific, traceable root cause. This guide walks you through the Power Pages governance framework from the ground up, including how to lock down DLP policies without breaking your site, how to configure admin settings correctly, and what to check when things go wrong.
The Quick Fix, Restore Blocked DLP Access Fast
If your Power Pages site suddenly stopped working after a recent change to your tenant's DLP policies, and users are seeing errors when submitting forms or accessing Dataverse-connected pages, here's the fastest path to diagnosis and recovery.
First, get to the right place. Open the Power Platform admin center at admin.powerplatform.microsoft.com, sign in with your admin account, and navigate to Policies > Data policies. You're looking for any policy that applies to the environment your Power Pages site lives in.
What you're hunting for: the Microsoft Dataverse connector and the Power Pages connector. If either of these has been moved from the "Business" group to "Non-business" or "Blocked," that's almost certainly your culprit. DLP policies use a three-tier classification, Business, Non-business, and Blocked. Connectors in different tiers cannot communicate with each other in the same flow or site action. The moment Dataverse gets separated from a connector your site depends on, the communication breaks silently.
To fix it: select the policy, click Edit Policy, navigate to the Prebuilt connectors step, find the Microsoft Dataverse connector, and drag it into the same group as the other connectors your site uses. Save the policy. Changes propagate within minutes, no site restart needed.
If your site uses Power Automate cloud flows triggered from form submissions, also check that the Power Automate Management and any HTTP connectors involved in those flows are in a compatible group.
Before you configure anything, you need a clear picture of what you're working with. Head to admin.powerplatform.microsoft.com and select Environments from the left nav. Find the environment that hosts your Power Pages site, it'll typically be a production or sandbox environment with Dataverse enabled.
Click into that environment and review four things:
- Type, Is it Production, Sandbox, or Default? Power Pages sites in Default environments have reduced governance options and aren't recommended for external-facing sites.
- Dataverse, Confirm Dataverse is provisioned. Power Pages stores all site configuration, content, and business data in Dataverse. Without it, nothing works.
- Security group, Check whether a security group is scoped to this environment. If your Power Pages site is meant for external anonymous or authenticated users, make sure the environment isn't accidentally locked to an internal AAD group only.
- Capacity, Look at the storage consumption. If you're over the Dataverse storage allocation for your tenant, the environment can enter a degraded state. This is a quiet killer, the site stays up but form submissions and data writes start failing.
If you see a yellow warning triangle next to any of these values, that's your first signal that something needs attention before you go further. Fix environment-level issues before touching site-level configurations, otherwise you'll keep chasing symptoms instead of causes.
Once you've confirmed the environment is healthy, scroll down to find the Power Pages sites section within the environment detail. This shows you all sites provisioned in this environment, their current state (active, inactive, error), and the site URL. An "Error" status here usually points to provisioning problems or licensing issues, both covered in the steps below.
Power Pages governance lives and dies on how well your DLP policies are structured. Getting this right is the single most important admin task you'll do, and the one most organizations get wrong the first time.
Navigate to Policies > Data policies in the admin center. You'll likely see one or more policies, some tenant-wide, some scoped to specific environments. Here's the rule: environment-scoped policies take precedence over tenant-wide policies when they're more restrictive. So even if your tenant-wide policy looks fine, a stricter environment policy could still be the blocker.
For a standard Power Pages configuration, the following connectors must be in the same DLP group (I recommend "Business"):
- Microsoft Dataverse
- Microsoft Dataverse (legacy)
- Any Power Automate connectors triggered by your site's forms (HTTP, custom connectors, Office 365 connectors if you're sending email notifications)
# PowerShell check, list all DLP policies affecting an environment
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell
Get-DlpPolicy | Where-Object {$_.Environments -contains "your-environment-id"}The output will show you policy name, creation date, and which environments it applies to. Cross-reference this against your site's environment ID (found in the environment detail URL in the admin center, it's the GUID in the path).
When you create a new DLP policy scoped specifically for your Power Pages environment, you get more precise control without disrupting other environments. In the policy wizard, on the Scope step, choose "Add multiple environments" and select only the environment your site lives in. This is the approach I always recommend for production Power Pages sites, it insulates them from tenant-wide policy changes.
This is where I see the most support tickets. Web roles are Power Pages' way of controlling what authenticated users can see and do on your site. Table permissions control what data those users can read, write, update, or delete in Dataverse. Both have to be configured, and they have to be linked to each other, or your users will hit invisible walls.
Open the Portal Management app for your site. You can get there through the Power Pages design studio by clicking Set up > Administration, or directly from the environment's app list in make.powerapps.com.
Inside the Portal Management app, navigate to Security > Web Roles. You should see at minimum two default roles: Anonymous Users and Authenticated Users. Any custom roles your site needs (like "Customer," "Partner," "Admin") need to be created here.
Once a web role exists, go to Security > Table Permissions and create a table permission record for each Dataverse table your site interacts with. Each permission record needs:
- Table Name, the exact Dataverse table logical name (e.g.,
contact,cr123_serviceticket) - Access Type, Global, Contact, Account, Self, or Parent-Child. For most external user scenarios, "Contact" or "Self" access is correct. "Global" gives every user access to every record, don't use this for sensitive data.
- Privileges, check Read, Write, Create, Append, Append To as needed. Be conservative here: start with the minimum and expand as users report issues.
- Web Roles, scroll to the bottom and add the web roles that should have this permission.
After saving, test by signing into the site as a user with that role. If data still doesn't appear, check that the web role is actually assigned to the contact record in Dataverse, the role has to be on the Contact record, not just defined in the Portal Management app.
Authentication failures in Power Pages are among the most disruptive issues an admin can face, they lock every external user out of the site instantly. The most common scenario: your Azure AD (now Entra ID) app registration either expired, got its redirect URIs changed, or had a secret rotate without being updated in Power Pages.
Start in the Power Pages design studio. Select your site, then go to Set up > Identity providers. You'll see a list of configured authentication providers. If Azure AD is shown with a warning icon or "Configuration required" status, that's the problem.
Click the provider to edit it. The key fields to verify:
Authority URL:
https://login.microsoftonline.com/{your-tenant-id}/v2.0
Redirect URL (must match exactly in Azure app registration):
https://{your-site-url}/signin-{provider-name}
Client ID: [from Azure app registration]
Client Secret: [must be current, non-expired]Now cross-check these values in Azure Portal > App registrations > Your App > Authentication. The redirect URI in Azure must exactly match what Power Pages expects, including the trailing slash behavior and the provider name slug. A single character difference means a failed redirect and a confused user.
If the client secret has expired, generate a new one in Azure Portal under Certificates & secrets, copy the value immediately (you won't see it again), and paste it into the Power Pages identity provider configuration. After saving, wait about two minutes for the change to propagate, then test with a fresh browser session in incognito mode.
For enterprise environments using Entra ID external authentication with conditional access policies, make sure the Power Pages app registration is excluded from any CA policies that would block non-corporate devices, otherwise your external users will hit an access block that looks like a site error but is actually a CA policy rejection.
Power Pages licensing is one of the least-understood parts of the platform, and getting it wrong either causes your site to degrade quietly or generates a sudden outage when a capacity threshold is crossed. Microsoft's documentation is clear on this: you need to assign the correct licensing before going live, and you need to monitor consumption actively afterward.
Power Pages uses a per-site subscription model for basic authenticated user capacity, plus additional capacity packs for higher volumes. Here's how to check your current state:
Go to Power Platform admin center > Billing > Licenses. Look for "Power Pages authenticated users per website/month" and "Power Pages anonymous users per website/month" entries. The numbers here tell you what's allocated at the tenant level.
Then go to Resources > Capacity > Add-ons and check how that capacity is distributed across environments. If your production environment isn't assigned sufficient authenticated user capacity, users will start seeing throttling errors once you exceed the monthly threshold, typically showing up as slow page loads, failed form submissions, or HTTP 429 errors in the browser console.
To assign capacity to an environment from the admin center:
Admin Center → Resources → Capacity → Add-ons
→ Assign to environments
→ Select your environment
→ Adjust "Power Pages authenticated users" slider
→ SaveAlso review Dataverse storage consumption at the environment level. Power Pages stores all site configuration in Dataverse tables, pages, web templates, entity forms, lists, site settings. In large, long-running sites this can add up. If Dataverse storage is over 85% of allocation, start a cleanup conversation with your team before it becomes a crisis. Archived site configurations and stale entity form records are common culprits.
After confirming licensing is clean, run through Microsoft's official go live checklist one final time. It covers site binding, SSL certificate status, custom domain configuration, and CDN settings, all of which interact with governance and can cause site errors if misconfigured before launch.
Advanced Troubleshooting for Power Pages Governance Issues
Once you've worked through the step-by-step fixes and something is still broken, it's time to go deeper. Here's how I approach enterprise-level Power Pages governance problems that don't respond to the standard fixes.
Using the Portals Admin Center for Diagnostic Data
The Power Pages Portals Admin Center is separate from the main Power Platform admin center, and most admins don't even know it exists. Access it by going to admin.powerplatform.microsoft.com, selecting your site from the Resources section, and clicking Manage. This opens the dedicated portals admin experience.
Inside, look for the Site Actions panel. This is where you can restart the site (which clears the site cache, solves about 20% of "it should be working but it's not" problems), clear the server-side cache explicitly, and check the Error Log for site-level exceptions.
The error log entries here are far more specific than anything users see on the front end. Common entries I watch for:
PortalDatabaseException: The request is blocked by DLP policy, confirms a DLP conflictEntityPermissionDenied: Access to table [tablename] is denied for role [rolename], table permission gapAuthenticationProviderException: Token validation failed, identity provider secret or configuration issueLicenseCapacityExceeded: Monthly authenticated user limit reached, capacity problem
Power Platform CLI for Governance Automation
For teams managing multiple Power Pages sites across multiple environments, manual admin center work doesn't scale. The Power Platform CLI gives you programmatic access to governance configurations.
# Install Power Platform CLI
npm install -g @microsoft/powerplatform-cli
# Authenticate
pac auth create --environment "your-environment-url"
# List all sites in the environment
pac paportal list
# Download site configuration for review/backup
pac paportal download --path ./site-backup --webSiteId "your-site-id"The download command pulls all site configuration, including web roles, table permissions, site settings, and web templates, into a local folder structure. This is invaluable for governance audits: you can diff configurations between environments, spot unexpected changes, and restore known-good states during incidents.
Event Viewer and Application Lifecycle Management
For domain-joined environments where Power Pages connects to on-premises data through a data gateway, check Windows Event Viewer on the gateway machine under Applications and Services Logs > Microsoft > DataManagementGateway. Event IDs 100 (gateway startup), 105 (connection failure), and 302 (authentication failure) are the most relevant for Power Pages connectivity issues.
On the ALM side, if your organization uses the Power Platform build tools in Azure DevOps or GitHub Actions to promote site configurations between environments, make sure your pipeline includes a step to re-map connection references after deployment. Dataverse connection references don't carry over automatically between environments, this is a very common cause of "worked in dev, broken in prod" governance failures.
Group Policy Considerations
In organizations that manage browser settings via Group Policy Objects, Power Pages can be affected by policies that block third-party cookies, restrict JavaScript execution, or enforce strict Content Security Policy headers. External users on corporate networks sometimes hit these restrictions invisibly. The most common symptoms: the site loads but forms don't submit, the authentication redirect loop never completes, or embedded Power BI reports don't render inside Power Pages pages.
Check Chrome/Edge Group Policy settings under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome or HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge for any CookiesBlockedForUrls or JavaScriptBlockedForUrls entries that might match your Power Pages domain.
Prevention & Best Practices for Power Pages Governance
The best Power Pages governance problems are the ones you never encounter because you set the environment up correctly from the start. After working with enterprise Power Pages deployments across industries, here are the practices that consistently keep sites stable and compliant.
Dedicate an environment per Power Pages site in production. The default environment is shared across your entire tenant, any change to its DLP policy, security groups, or Dataverse configuration affects every app and site running there. For any external-facing Power Pages site, provision a dedicated production environment. Yes, it costs more. Yes, it's worth it every time.
Version-control your site configuration using the Power Platform CLI. Run pac paportal download after every significant change and commit the output to a Git repository. This gives you an audit trail of every configuration change, who changed what, when, and a fast rollback path if something breaks after a deployment.
Set up monitoring before you go live. Power Pages doesn't send alerts by default when capacity thresholds are approached or when the error rate spikes. Wire up an Azure Monitor alert on the Dataverse environment's storage capacity, and use Power Automate to build a simple daily check that hits a known page on your site and sends an email if the response code isn't 200. Crude but effective.
Document your web role and table permission matrix. In any site with more than three roles, the relationship between web roles, table permissions, access types, and privileges becomes hard to reason about quickly. Keep a simple spreadsheet, Role × Table × Privilege, and update it every time you change permissions. When something breaks, this matrix is the first thing you reach for.
Test DLP policy changes in a sandbox environment first. Create a copy of your production Power Pages site in a sandbox environment (use pac paportal upload to push the same configuration). Apply DLP policy changes there first, verify the site still functions end-to-end, then apply to production. This one habit eliminates the most common source of governance-related outages.
- Set a calendar reminder to review Power Pages capacity consumption on the 1st of every month, catch capacity issues before they become outages
- Rotate Azure AD / Entra ID client secrets on a 90-day schedule and update Power Pages authentication configuration the same day
- After any tenant-wide DLP policy change, immediately log into your Power Pages site and submit a test form to confirm nothing broke
- Use the Power Pages go live checklist in the official documentation as a governance audit tool for existing sites, not just new ones, run through it quarterly
Frequently Asked Questions
My Power Pages site stopped working after a DLP policy change, how do I find out which connector got blocked?
Go to the Power Platform admin center, navigate to Policies > Data policies, and open each policy that applies to your site's environment. Look specifically at which group the Microsoft Dataverse connector is in. If it's in "Non-business" or "Blocked" while another connector your site depends on is in "Business," that's the conflict. You can also check the portal error log in the Portals Admin Center, an entry like The request is blocked by DLP policy will appear with a timestamp that lines up with when the problem started. Fix the connector grouping in the policy, wait two to three minutes, and test the site again.
Why can authenticated users log in but can't see any data on the pages that should show Dataverse records?
This is almost always a table permissions problem. The user is authenticated, their web role is assigned, but the table permission record that grants read access to the Dataverse table either doesn't exist, has the wrong access type, or isn't linked to the correct web role. Open the Portal Management app, go to Security > Table Permissions, find the permission for the relevant table, and verify that the user's web role is in the "Web Roles" subgrid at the bottom of the record. Also check that the Contact record in Dataverse for that user has the web role directly associated, this is a separate step from the Portal Management app configuration.
How do I know if my Power Pages site is approaching its authenticated user capacity limit?
Navigate to Power Platform admin center > Resources > Capacity > Add-ons and look for the "Power Pages authenticated users" row for your environment. This shows current allocation versus consumption. Microsoft also sends tenant admin email notifications when you approach 80% of any capacity threshold, make sure the admin notification email address in your tenant is actively monitored. If you're running a high-traffic site, build a Power Automate flow that queries capacity metrics daily via the Power Platform admin connectors and sends a summary to your team.
We promoted a Power Pages configuration from sandbox to production using the CLI and now forms aren't submitting, what's wrong?
The most likely culprit is connection references. When you push a site configuration to a new environment using pac paportal upload, any Power Automate cloud flows that the site triggers carry over their configuration, but the connection references inside those flows still point to sandbox credentials and connections. You need to go into make.powerautomate.com in the production environment, find the flows your site uses, open each one, and update the connection references to use production-environment connections. After updating, make sure the flows are turned on, they sometimes land in production in a disabled state.
What's the difference between the Power Platform admin center and the Portals Admin Center, and which one should I use for governance?
These are two separate tools with overlapping but distinct scopes. The Power Platform admin center at admin.powerplatform.microsoft.com handles tenant-level governance: DLP policies, environment management, licensing and capacity, security groups, and ALM. The Portals Admin Center is accessed from within the admin center by clicking "Manage" on a specific site, it handles site-level operations: restarting the site, clearing the cache, checking site-specific error logs, managing custom domains and SSL certificates, and site actions like enabling/disabling maintenance mode. For governance work, you'll use both. Start with the Power Platform admin center to rule out environment and policy issues, then move to the Portals Admin Center for site-specific diagnostics.
Can I use Group Policy or Intune to control which users in my organization can create new Power Pages sites?
You can't use Group Policy or Intune directly for this, but the Power Platform admin center gives you equivalent control. Navigate to Settings > Tenant settings and find the "Power Pages creation" toggle. You can restrict site creation to specific security groups, which effectively prevents non-admin users from provisioning unauthorized sites in your tenant. This is the recommended governance control for organizations that want to prevent shadow IT Power Pages deployments. You can also use environment security groups to limit which users can access specific environments where Power Pages sites are provisioned.