Power Platform: Governance, DLP Policies, and Admin Configuration Guide
Why This Is Happening
Here's a scenario I see constantly: a well-meaning developer in your organization builds a Power Automate flow that connects your company's SharePoint data directly to a personal Gmail account. No malicious intent , they just needed to forward some files quickly. By the time IT notices, that flow has been running for weeks. Sound familiar?
Power Platform governance problems don't announce themselves with a dramatic error message. They creep in silently through misconfigured environments, missing DLP policies, and admin settings that nobody touched after initial tenant setup. I've seen organizations with hundreds of apps and flows running in their default environment with zero guardrails , and then something breaks, leaks, or gets flagged by compliance, and suddenly everyone wants answers.
The root causes typically fall into a few buckets. First, Power Platform environments are created without a clear strategy, developers get free rein in the default environment, production solutions share space with experimental ones, and there's no separation between dev, test, and prod. Second, Data Loss Prevention (DLP) policies either don't exist or were set up once and never revisited as new connectors were added. Third, the Power Platform admin center itself has a learning curve, and many admins configure it reactively rather than proactively.
There's also a visibility problem. Power Platform's error messages around policy violations are notoriously vague. When a flow fails because a connector is blocked by a DLP policy, the error often reads something like "The connector 'shared_gmail' is blocked by the DLP policy in this environment", which tells you what happened but not where to go fix it, or whether that policy was intentional.
Who sees these issues most? Usually it's a mix of citizen developers hitting walls they don't understand, and IT admins who inherited a tenant with no documentation. Both groups are frustrated, and rightfully so. Microsoft's official documentation is thorough but dense, it assumes you already know the difference between a tenant-level policy and an environment-level policy, for example.
The good news: Power Platform governance is very fixable. The admin center, DLP policy editor, and environment management tools are mature and capable. You just need to know where to look and what order to do things in. That's exactly what this guide covers. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If you're getting a DLP policy violation error on a flow or app right now, here's the fastest path to diagnosis. Open the Power Platform admin center at admin.powerplatform.microsoft.com and sign in with your tenant admin account.
Go to Policies > Data policies in the left navigation. You'll see a list of all DLP policies scoped to your tenant and environments. Look for any policy that lists the environment where your broken flow lives. Click into it and select the Connectors tab. Check whether the connector your flow uses (say, Gmail, Salesforce, or a custom connector) is listed under Blocked or has been placed in a different group than what the flow expects.
If you find it blocked and the block was unintentional, here's the fix:
- Click Edit Policy on the offending DLP policy.
- On the Prebuilt connectors page, locate the connector using the search bar.
- Drag it from the Blocked column to either Business or Non-business, whichever group your flow's other connectors belong to.
- Click Next through the remaining wizard steps and select Create policy (or Update policy if editing).
Once saved, go back to your flow, open it, and click Save (even without changes). This forces a policy re-evaluation. Then do a test run. In most cases, this resolves the immediate block.
If you don't see any obvious blocked connectors, the issue might be a connector group mismatch, two connectors are in different groups (one in Business, one in Non-business), and DLP rules prevent mixing them in the same flow. That's a slightly more involved fix covered in Step 3 below.
Before you touch any policy or environment setting, you need a clear picture of what's already there. Log into the Power Platform admin center at admin.powerplatform.microsoft.com. You'll need either the Power Platform Administrator role or the Global Administrator role in your tenant.
From the home dashboard, click Environments in the left rail. This lists every environment in your tenant, including the default environment, any developer environments, and any sandbox or production environments someone has created. Take note of:
- How many environments exist (more than 10 with no naming convention is a red flag)
- Which environments have no description or owner listed
- The Type column, make sure production workloads aren't sitting in Default or Trial environments
Next, head to Policies > Data policies. Count the policies and check their Applied to scope. A policy scoped to "All environments" is a tenant-wide rule, it overrides environment-specific policies and cannot be loosened at the environment level. Environment admins can only tighten rules, never relax what a tenant-level policy enforces.
Run this PowerShell snippet to export a quick inventory of your environments. You'll need the Power Platform admin module installed first:
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Force
Import-Module Microsoft.PowerApps.Administration.PowerShell
Add-PowerAppsAccount
Get-AdminPowerAppEnvironment | Select-Object DisplayName, EnvironmentType, IsDefault, Location | Export-Csv -Path ".\pp_environments.csv" -NoTypeInformationIf this runs without errors, you'll get a CSV file in your current directory. Open it, you want to see clean naming conventions, no mystery environments, and proper type assignments. If you see a pile of environments named "John's Environment" or "Test123", that's governance work ahead of you..
I cannot stress this enough: trying to write DLP policies without a clear environment strategy is backwards. The two are deeply connected, and getting the environment structure right first makes everything downstream easier.
Microsoft's official guidance recommends at minimum a three-tier environment model: Development, Test/UAT, and Production. In reality, most organizations also need a fourth: a Default environment with strict restrictions, used only for personal productivity apps, not production workloads.
To create a properly typed environment, go to Environments > + New in the admin center. Fill in:
- Name: Use a convention like
[Department]-[Purpose]-[Region], e.g.,Finance-Production-US - Type: Choose Sandbox for dev/test, Production for live workloads
- Region: Match to your data residency requirements
- Dataverse: Enable it if you'll be using model-driven apps or Copilot Studio agents
One thing admins miss: you can change the environment type after creation. Go to the environment detail page, click Edit, and change the Type field. Converting a Sandbox to Production, for example, removes the 30-day automatic deletion risk that sandbox environments carry. Speaking of which, Power Platform automatically deletes inactive sandbox environments after 90 days without a recent activity check-in. You can disable this auto-deletion behavior from Settings > Automatic deletion policies inside the environment detail view.
Once your environment structure is mapped out on paper (seriously, sketch it out), you're ready to write DLP policies that align with it rather than conflict with it.
DLP policies in Power Platform control which connectors can be used together in a flow or app. The core concept is connector groups: Business, Non-business, and Blocked. Connectors within the same group can talk to each other freely. Connectors in different groups cannot be combined in the same flow. Blocked connectors can't be used at all.
To create a new DLP policy, go to Policies > Data policies > + New Policy. Give it a descriptive name like Production-Strict-DLP. Walk through the wizard:
- Prebuilt connectors: This is where you sort Microsoft's standard connectors. Move SharePoint, Teams, Dataverse, and Outlook to Business. Move personal connectors like Gmail and Dropbox to Non-business. Block anything you never want used, like specific third-party data platforms.
- Custom connectors: On this tab you'll set rules for custom connectors by URL pattern. For example, block
https://*.untrusted-api.com/*as a pattern. - Scope: Choose whether this policy applies to all environments, specific environments, or all except specific environments. For your most restrictive policies, scope to production environments. For your default environment, create a separate policy.
One connector group rule that trips people up constantly: if Office 365 Outlook is in Business and SharePoint is also in Business, great, they can work together. But if someone adds a Gmail step and Gmail is in Non-business, the entire flow fails at save time with the error: "This flow uses connectors across different data groups." The fix is either move Gmail to Business (if your policy allows it) or split the logic into two separate flows.
# PowerShell: List all DLP policies in tenant
Get-DlpPolicy | Select-Object DisplayName, PolicyScopes, CreatedBy, CreatedTime | Format-Table -AutoSizeAfter saving your policy, give it 5–10 minutes to propagate. Policy enforcement is near-real-time but not instant.
Environment access in Power Platform is controlled by two layers: Azure AD role assignments (tenant level) and Dataverse security roles (environment level). Getting these confused is one of the most common admin mistakes I see.
At the tenant level, the roles that matter are:
- Power Platform Administrator: Full admin access to admin center, all environments, all DLP policies. Cannot access Dynamics 365 apps by default.
- Environment Admin: Scoped to specific environments. Can manage environment settings and security but cannot create tenant-level DLP policies.
- Environment Maker: The default role that allows creating apps, flows, and connections. Does not grant access to data.
To assign someone as an Environment Admin for a specific environment, go to Environments > [Your Environment] > Settings > Users + permissions > Administrators. Add the user there. This does not automatically give them a Dataverse security role, those are managed separately inside the environment itself.
Inside an environment with Dataverse enabled, navigate to Settings > Users & permissions > Security roles. Create or assign security roles based on least-privilege principles. For example, a flow that reads from a custom Dataverse table only needs the Basic User role plus a custom role granting read on that specific table, not System Administrator.
A common gotcha: when you add a new user to an environment, they don't automatically get any Dataverse security role. The flow or app they try to use will fail with a permission error until you explicitly assign them a role. Always test with a non-admin account after setting up new security configurations.
Once governance is in place, you need visibility into what's actually running. Power Platform admin center has built-in analytics, but many organizations don't realize how powerful they are.
Go to Analytics > Power Automate or Analytics > Power Apps to see usage data across environments. You can filter by environment, time range, and resource type. Look for:
- Flows running in the default environment that should be in a managed environment
- Apps with no recent activity (candidates for cleanup)
- Connectors being used that you thought were blocked (a sign a DLP policy scope is wrong)
For enterprise-scale governance, Microsoft offers the Center of Excellence (CoE) Starter Kit, a collection of pre-built apps, flows, and Power BI dashboards that sit on top of your tenant and give you a governance cockpit. It's free and available from the official documentation. Installing it requires a dedicated environment and a service account, but once deployed, it answers questions like "who owns this app?" and "which flows haven't run in 90 days?" in seconds rather than hours of manual digging.
# Check for flows with DLP violations via PowerShell
Get-AdminFlow -EnvironmentName "your-environment-id" |
Where-Object { $_.Internal.properties.definitionSummary.triggers -ne $null } |
Select-Object DisplayName, CreatedBy, LastModifiedTime | Format-TableAlso consider enabling tenant isolation if your organization needs to prevent cross-tenant connector usage. This setting, found under Settings > Power Platform settings > Tenant isolation, blocks connectors from authenticating to other Azure AD tenants, a key control for compliance-heavy industries like finance and healthcare. After enabling it, test your critical flows immediately, as this setting can silently break flows that connect to partner tenants.
Advanced Troubleshooting
When the standard fixes don't resolve your Power Platform governance issue, it's time to dig deeper. Here are the scenarios I get escalated most often.
DLP policy isn't taking effect. You saved a policy change 30 minutes ago and the flow is still failing the same way. First, check policy scoping, if the environment is listed under the "Exclude" list of your policy, the policy simply doesn't apply there. Go to Policies > Data policies > [Policy] > Scope and verify. Second, check whether a more restrictive tenant-level policy overrides what you just changed. Tenant-level policies always win. A connector can't be in Business at the environment level if the tenant policy says Blocked.
Environment not showing in admin center. If you can't see an environment you know exists, check your admin role. Power Platform Administrator sees all environments. Environment Admin only sees the specific environments they're assigned to. Also check whether the environment is in a different geographic region, the admin center filters by region in some views. Use this PowerShell command to list everything regardless of region:
Get-AdminPowerAppEnvironment -EnvironmentName "environment-guid-here"Connector blocked even though DLP says it's allowed. This almost always means there are two overlapping policies and you're looking at the wrong one. Run:
Get-DlpPolicy | Where-Object { $_.PolicyScopes.environments -contains "your-env-id" -or $_.PolicyScopes.allEnvironments -eq $true }This surfaces every policy that touches your environment. Cross-check connector placement in all of them.
Users getting "Access Denied" on a canvas app in production. This is almost always a missing Dataverse security role. Even if the user has the Environment Maker role in Azure AD, that doesn't grant data access. Open the app in Power Apps Studio, go to the environment, find the user under Settings > Users, and verify their Dataverse security roles are assigned. The minimum for most read-only apps is Basic User.
ALM deployment failures between environments. If you're using solutions to move apps between dev, test, and production and the import is failing, the most common culprits are connection references and environment variables. Connection references need to be re-mapped in the target environment because they point to specific user credentials. During solution import, you'll be prompted to update these, don't skip that step. Environment variables that have no default value and no current value in the target environment will cause the import to succeed but the flow to fail silently on first run.
Prevention & Best Practices
Good Power Platform governance isn't a one-time setup, it's an ongoing practice. The organizations that handle this well treat it the same way they treat any infrastructure: with documentation, automation, and regular review cycles.
Start by establishing an environment request process. Instead of letting anyone create environments on demand, require a simple request form (ironically, a Power App works great for this). Capture the business purpose, expected lifespan, data classification, and owner. This alone cuts environment sprawl by 70% in most organizations I've worked with.
Write your DLP policies top-down. Start with the most restrictive tenant-wide policy first, block everything that's not explicitly approved. Then create environment-specific policies that loosen restrictions for specific use cases in specific environments. Document every exception and the business justification for it.
Use the Power Platform Center of Excellence Starter Kit to automate governance tasks. It includes flows that automatically notify app owners when their apps haven't been used in 90 days, quarantine apps that violate policies, and generate weekly governance reports to your admin team's email.
Conduct a quarterly DLP policy review. Microsoft adds new connectors regularly, new connectors default to the Non-business group, which sounds safe, but if your tenant-level policy has Non-business set to very permissive rules, new connectors inherit that permissiveness automatically. A quarterly review catches these additions before they become a compliance gap.
Finally, test your governance setup from a non-admin account before declaring it production-ready. Most admins have elevated permissions that bypass the exact restrictions they just set up. Create a test user with the Environment Maker role only and try to do what your citizen developers actually do. You'll find gaps fast.
- Enable tenant isolation immediately if you handle regulated data, it prevents connectors from authenticating to foreign tenants without explicit allow-listing.
- Set the default environment's DLP policy to block all non-Microsoft connectors, personal productivity should not touch external APIs.
- Assign an explicit owner to every environment in the admin center description field; orphaned environments are a governance liability.
- Enable audit logging in the admin center under Analytics > Audit Logs, you want a paper trail when something goes wrong, not to be scrambling after the fact.
Frequently Asked Questions
What is the difference between a tenant-level DLP policy and an environment-level DLP policy in Power Platform?
A tenant-level DLP policy applies across all environments in your Microsoft 365 tenant and is managed exclusively by tenant admins or Power Platform admins. An environment-level policy only applies to specific environments you designate. Here's the key rule: environment-level policies can only be more restrictive than tenant-level policies, never more permissive. So if your tenant policy blocks Gmail, no environment policy can unblock it. Environment admins can create environment-level policies for their own environments, but they can't override what the tenant admin has set above them.
My Power Automate flow says it's blocked by a DLP policy but I can't find which one, how do I track it down?
This is a common frustration and the error message really doesn't help. The fastest way to find the culprit is via PowerShell: run Get-DlpPolicy from the Power Apps administration module and look for policies whose scope includes your environment ID or "all environments." Then check each policy's connector groupings for the connector your flow is trying to use. If you're not comfortable with PowerShell, go to admin.powerplatform.microsoft.com > Policies > Data policies, click each policy, and check the Connectors tab, sort by "Blocked" to find restricted connectors quickly. Remember to check all policies, not just the most recently modified one.
How do I stop Power Platform from automatically deleting my sandbox environments?
Power Platform automatically flags inactive sandbox environments for deletion after 90 days and sends email warnings before doing so. You have two options to stop this. First, you can simply use the environment, any run of an app or flow resets the inactivity clock. Second, you can convert the environment type from Sandbox to Production or Developer, which removes it from the auto-deletion policy entirely. To change the type, go to the environment's detail page in the admin center, click Edit, and change the Type field. Note that converting to Production counts against your production environment license allocation, so check your licensing first.
What is ALM in Power Platform and why does everyone keep talking about it?
ALM stands for Application Lifecycle Management, it's the process of moving your Power Platform solutions (apps, flows, chatbots) from development through testing to production in a controlled, repeatable way. Without ALM, developers make changes directly in production, there's no version history, and rollbacks are painful or impossible. Microsoft's recommended ALM approach uses Solutions to package related components, environments to separate dev/test/prod, and tools like Azure DevOps or GitHub Actions with the Power Platform Build Tools to automate deployments. If you're still manually exporting and importing solution ZIP files by hand, that's the beginning of ALM, but automating it with pipelines is where the real reliability gains come from.
Can citizen developers in my organization create their own environments, and should I allow that?
By default, any licensed user can create their own developer environment, and in many organizations this is fine for experimentation. The risk isn't individual environments themselves; it's unmanaged environments with no DLP policies connecting sensitive business data to consumer services. You can restrict environment creation to admins only by going to admin.powerplatform.microsoft.com > Settings > Power Platform settings > Who can create trial environments and Who can create production and sandbox environments, set both to "Only specific admins." Then create a formal request process so developers can still get environments when they need them, just with proper policies attached from day one.
How do I move a Power Platform solution from dev to production without breaking connection references?
Connection references are the most common source of broken deployments. When you import a solution into a target environment, each connection reference needs to be mapped to a valid connection in that environment, you can't reuse the dev user's personal credentials in production. During the import wizard in Power Apps, you'll see a step called "Connections" where you map each reference. Create service account connections in your production environment ahead of time (not personal user accounts), and map to those. For automated deployments via Azure DevOps or GitHub Actions, use the Power Platform Deploy Solution task and supply a deployment settings file (deploymentsettings.json) that pre-maps connection references and environment variables for the target environment. This eliminates the manual mapping step entirely.