Power Platform Governance & COE — Complete Guide
Governance Fundamentals · DLP Policies · Environment Strategy · COE Starter Kit · ALM · Pipelines · Scenarios · Cheat Sheet
Table of Contents
- Governance Fundamentals
- Data Loss Prevention (DLP) Policies
- Environment Strategy & Lifecycle
- COE Starter Kit & Adoption
- ALM & Deployment Pipelines
- Monitoring, Auditing & Compliance
- Scenario-Based Questions
- Cheat Sheet — Quick Reference
1. Governance Fundamentals
What is Power Platform governance and why does it matter?
Power Platform governance is the set of policies, processes, and tools that ensure the platform is used securely, efficiently, and in alignment with organisational standards.
Without governance:
- Users create apps connecting to sensitive data without security reviews
- Connectors expose corporate data to external services (consumer apps, personal accounts)
- Hundreds of unmanaged environments consume capacity and storage with no oversight
- Critical business processes run on flows owned by individuals who leave the organisation
- Compliance violations occur when personal data flows to unsanctioned services
Key insight: The governance challenge is unique to Power Platform — it is a self-service platform by design. The goal is to enable innovation while preventing data leakage, shadow IT, and orphaned resources.
What are the three pillars of Power Platform governance?
| Pillar | Focus Areas |
|---|---|
| Security & Compliance | DLP policies, connector restrictions, Azure AD conditional access, tenant isolation, data residency, sensitivity labels |
| Environment Management | Environment strategy (dev/test/prod), capacity planning, lifecycle (creation, monitoring, cleanup), access control |
| Adoption & Enablement | COE governance, training programmes, maker communities, app catalogues, support models, usage analytics |
Tip: Governance without adoption = platform stagnation. Adoption without governance = security risk. Balancing the two is the central tension in Power Platform architecture.
What admin roles exist for Power Platform and what can each do?
| Role | Scope | Use Case |
|---|---|---|
| Global Administrator | Full M365 + Power Platform | Too broad — avoid for regular admin |
| Power Platform Administrator | All environments, DLP, capacity, connectors, tenant settings | Primary Power Platform admin role |
| Dynamics 365 Administrator | D365 environments specifically | D365-focused admin |
| Environment Administrator | One specific environment | Delegated env-level management |
| System Administrator (Dataverse role) | Full access within one Dataverse environment | Customise, configure, manage data |
Warning: Never assign Global Administrator for Power Platform administration. Use Power Platform Administrator — it has the right scope without unnecessary M365 access.
What is the Power Platform Admin Center and what can you manage from it?
The Power Platform Admin Center (admin.powerplatform.microsoft.com) is the central management portal.
| Capability | Description |
|---|---|
| Environments | Create, configure, copy, reset, delete environments. Manage capacity and storage. |
| DLP policies | Create and manage Data Loss Prevention policies across tenant and environments. |
| Analytics | Usage reports for Power Apps, Power Automate, Copilot Studio across the tenant. |
| Capacity | Monitor Dataverse storage, file storage, log storage per environment. |
| Connectors | View and manage custom connectors across the tenant. |
| Tenant settings | Control who can create environments, AI features, sharing settings. |
| Support | Raise and manage Microsoft support tickets. |
What are the most important tenant-level settings for governance?
- Who can create production/sandbox environments — restrict to admins only. Prevents environment sprawl.
- Who can create trial environments — balance exploration vs sprawl.
- Power Apps/Power Automate for M365 users — enable/disable for specific Azure AD groups.
- AI features (Copilot) — enable/disable generative AI features tenant-wide.
- Sharing canvas apps — restrict who users can share apps with (organisation, specific groups, admins only).
- Weekly digest emails to makers — notify makers when their resources are flagged.
Tip: Restricting environment creation to admins only is the single most impactful governance setting — it prevents the #1 governance problem: uncontrolled environment sprawl.
2. Data Loss Prevention (DLP) Policies
What are DLP policies in Power Platform and how do they work?
DLP policies control which connectors can be used together in a flow or app. They prevent sensitive business data from being exfiltrated to unsanctioned services by enforcing connector grouping rules.
Three connector groups:
| Group | Description | Examples |
|---|---|---|
| Business | Approved connectors for business data | SharePoint, Dataverse, Teams, Outlook, SQL Server, Azure |
| Non-business (Personal) | Consumer/personal connectors | Twitter, Facebook, Gmail, personal OneDrive, Dropbox |
| Blocked | Cannot be used at all in this environment | High-risk or unvetted connectors |
A flow or app can only use connectors from one group — Business OR Non-business, never both together. This prevents a flow from reading corporate SharePoint data and writing it to a personal Gmail.
Critical: An environment with no DLP policy allows any combination of connectors — corporate data can flow freely to consumer services. Always apply DLP before allowing maker access to an environment.
What is the difference between tenant-scoped and environment-scoped DLP policies?
Tenant-scoped DLP policy: applies to ALL environments in the tenant (or all except explicitly excluded ones). Set by Power Platform Administrator. Cannot be overridden by environment admins. Used for baseline security.
Environment-scoped DLP policy: applies to one or more specific environments. Can be set by Power Platform Admins or Environment Admins. Can be more restrictive than the tenant policy but never more permissive — tenant policy always wins.
Tenant policy (baseline): Environment policy (stricter):
Business: SharePoint, Teams Business: SharePoint only
Non-business: Gmail, Twitter Blocked: Teams, Gmail, Twitter
Effective result for that environment:
= most restrictive combination of both policies
→ SharePoint in Business, Teams blocked, Gmail blocked
Tip: Always create a baseline tenant-wide DLP policy first. Then add environment-specific policies for additional restrictions in sensitive or production environments.
What are connector action controls in DLP policies?
Connector action controls allow admins to permit or block specific actions within a connector — rather than blocking the entire connector. This provides fine-grained control.
SharePoint connector action controls:
Allow: Get items, Get item, Create item, Update item
Block: Delete item, Delete attachment
HTTP connector action controls:
Allow: GET requests only
Block: POST, PUT, DELETE requests
→ Allows reading external APIs but prevents writing data out
Dataverse connector action controls:
Allow: List rows, Get row, Create row, Update row
Block: Delete row, Execute action, Perform bulk operations
Tip: Connector action controls are a governance maturity milestone — they allow enabling a connector for legitimate use while preventing its abuse. Much more nuanced than all-or-nothing connector blocking.
What are endpoint filtering rules in DLP policies?
Endpoint filtering rules restrict which specific URLs or hosts the HTTP connector, custom connectors, or certain other connectors can connect to.
HTTP connector endpoint rules:
Allow list:
*.internal-company-api.com
https://api.approvedsystem.com
Deny list (default):
* (all other endpoints blocked)
Use case: allow Power Automate to call only internal
APIs — block calls to external/consumer services
via HTTP action even with custom endpoints
How do DLP policies interact with existing flows when a new policy is applied?
- When a DLP policy is created or changed, existing flows are evaluated against the new policy
- Flows that violate the new policy are suspended — they stop running immediately
- The flow owner receives an email notification that their flow has been suspended
- The flow remains suspended until: the policy is changed to permit the connectors, OR the flow is modified to comply
- Power Platform Admin Center shows which flows are suspended and which policy caused it
Warning: Applying a new restrictive DLP policy to an existing environment can immediately suspend production flows. Always audit existing flows before applying a new policy — use the COE Starter Kit inventory to identify potentially affected flows first.
3. Environment Strategy & Lifecycle
What is environment strategy in Power Platform and what are the recommended patterns?
Environment strategy defines how environments are structured, purposed, and managed across the organisation.
Recommended environment tiers:
| Tier | Purpose | Access | DLP |
|---|---|---|---|
| Default | Personal M365 productivity | All licensed users (restricted) | Strict — M365 connectors only |
| Developer | Individual maker experimentation | One maker only | Restrictive |
| Shared sandbox | Project development & testing | Project team | Standard business connectors |
| Test/UAT | Pre-production validation | QA team + business owners | Production-equivalent |
| Production | Live business applications | End users (read), admins | Most restrictive |
| COE/Admin | Governance tools and admin flows | COE team only | Permissive (for admin connectors) |
How do you prevent environment sprawl in a large organisation?
- Restrict environment creation — set "Who can create production and sandbox environments" to admins only in tenant settings
- Environment request process — implement a formal request flow (Power Automate approval). COE Starter Kit includes this out of the box.
- Environment lifecycle policies — auto-identify environments with no activity for 90 days via COE analytics → notify owners → delete if no response
- Trial environment controls — trial environments auto-expire after 30 days. Ensure cleanup is monitored.
- Regular audits — monthly review of all environments via COE Starter Kit inventory
Tip: Environment sprawl is the #1 governance problem in large tenants. Microsoft reports that uncontrolled tenants can have 1000+ environments — most unused. Proactive controls prevent this from the start.
What is the Default environment and what special considerations does it have?
| Characteristic | Detail |
|---|---|
| Existence | Every tenant has exactly one — cannot be deleted |
| Membership | All licensed users automatically added as Environment Makers |
| M365 flows | Teams, Outlook, SharePoint-triggered flows run here by default |
| Risk level | Highest risk — anyone can create apps and flows here |
Governance recommendations:
- Apply strict DLP — allow only M365/productivity connectors, block all premium and personal connectors
- Remove Environment Maker role from all users — grant only to approved individuals
- Rename to signal its purpose: "Default — Personal Productivity Only"
- Use COE Starter Kit to monitor and clean up unused resources regularly
Critical: The Default environment is the highest-risk environment in any tenant. Without governance it becomes a dumping ground for production apps with no oversight.
How do you handle environment capacity and storage management?
Three Dataverse storage types:
| Type | Contains |
|---|---|
| Database storage | Dataverse table data, relationships, metadata |
| File storage | Attachments, images, file columns |
| Log storage | Audit logs, plugin trace logs |
Capacity management practices:
- Monitor via Admin Center → Capacity → Summary
- Set storage alerts — get notified before hitting capacity limits
- Regularly purge audit logs older than the retention period
- Run Dataverse bulk delete jobs for old/inactive records
- Use Azure Blob or SharePoint for file storage instead of Dataverse file columns where possible
- Archive inactive environments' Dataverse data before deletion
4. COE Starter Kit & Adoption
What is the COE Starter Kit and what does it provide?
The Centre of Excellence (COE) Starter Kit is a free, open-source collection of Power Platform components published by Microsoft that helps organisations govern, monitor, and nurture their Power Platform adoption.
Key modules:
| Module | Description |
|---|---|
| Core components | Inventory of all apps, flows, connectors, environments, and makers across the tenant. Synced daily via admin APIs. |
| Governance components | Compliance processes — maker compliance emails, app archival, orphaned resource cleanup, environment request flows. |
| Nurture components | Adoption tools — maker onboarding, training resources, app showcase/gallery, hackathon management, community tools. |
| Audit & compliance | Risk assessment of apps/flows, DLP violation reporting, sensitivity analysis. |
| Power BI dashboard | Tenant-wide analytics — top makers, most used apps, connector usage, risk scores, environment health. |
Tip: The COE Starter Kit transforms Power Platform administration from reactive firefighting into proactive governance. It is the expected answer to "how do you govern Power Platform at scale."
What does the COE Core inventory collect and how does it work?
A scheduled cloud flow runs daily using the Power Platform Admin connector and Management APIs:
API calls:
Get Environments → all environments in tenant
Get Apps as Admin → all canvas and model-driven apps
Get Flows as Admin → all cloud flows
Get Connectors as Admin → all connectors used
Get Makers → all users who have created resources
Stored in Dataverse tables:
admin_Environment → all environments
admin_PowerApp → all canvas and model-driven apps
admin_Flow → all cloud flows
admin_Connector → all connectors used
admin_Maker → all users who have created resources
admin_PowerAppConnector → connector usage per app
admin_FlowConnector → connector usage per flow
Warning: The COE inventory sync requires a service account with Power Platform Administrator role. Use a dedicated service account — never a personal admin account (single point of failure risk).
What is the compliance process in the COE Governance module?
The governance module automates a compliance conversation with makers about their apps and flows:
- Admin emails makers of apps/flows that haven't been reviewed — asking for business justification, data classification, and owner confirmation
- Maker fills in a compliance form: app purpose, data sensitivity level, business owner, support contact
- If no response within the grace period: app/flow is quarantined (shared access removed)
- If still no response: app/flow is deleted (with backup)
- Compliant resources are tagged and exempted from future compliance sweeps
Tip: This automated compliance process cleans up years of accumulated shadow IT without manual effort. The grace period approach avoids disrupting legitimate users while enforcing governance.
What does a Power Platform Centre of Excellence team look like?
Three layers of a mature COE:
| Layer | Composition | Responsibilities |
|---|---|---|
| Central COE team | 2–5 people (Architect, Admin Lead, Enablement Lead) | Platform strategy, DLP, environment strategy, security standards, COE Starter Kit |
| Champions network | Power users/citizen developers in each BU | First-line support, evangelism, quality gatekeeping for department apps |
| Professional developers | IT/dev team | Complex solutions requiring pro-code extensions (PCF, plugins, custom APIs) |
Key principle: The COE's role is to enable — not gatekeep. The goal is a "managed self-service" model where makers can build freely within guardrails, not a bottleneck where everything goes through central IT.
What is the maker onboarding process in a governed environment?
- User requests maker access via a Power Automate approval flow
- Manager approves — confirms the maker needs to build on the platform
- Automated onboarding: assigned Environment Maker role in appropriate dev environment, added to makers Azure AD group, added to maker community Teams channel
- Welcome email with training resources, DLP policy overview, coding standards, ALM process documentation
- Mandatory Power Platform fundamentals training before first app published to production
- COE inventory automatically tracks the new maker and their subsequent resource creation
5. ALM & Deployment Pipelines
What is ALM for Power Platform and what does it involve?
ALM (Application Lifecycle Management) covers the processes and tools for developing, testing, and deploying Power Platform solutions in a controlled, repeatable way.
Core ALM elements:
| Element | Description |
|---|---|
| Source control | Solution files stored in Git (Azure DevOps or GitHub) — tracked, versioned, peer-reviewed |
| Solution packaging | All components in a managed solution (apps, flows, tables, connection references, env variables) |
| CI/CD pipelines | Automated export → unpack → commit → build → deploy |
| Environment promotion | Dev → Test/UAT → Production with gated deployments |
| Connection references | Environment-agnostic connection pointers |
| Environment variables | Environment-specific configuration values |
What is the Power Platform Build Tools and how is it used in CI/CD?
Power Platform Build Tools is an Azure DevOps extension (and GitHub Actions equivalent) providing pipeline tasks for automating Power Platform ALM.
# Typical CI pipeline (on commit):
- task: PowerPlatformToolInstaller@2
- task: PowerPlatformExportSolution@2
inputs:
authenticationType: 'PowerPlatformSPN'
Environment: '$(DevEnvironmentUrl)'
SolutionName: 'MyAppSolution'
SolutionOutputFile: '$(Build.ArtifactStagingDirectory)/solution.zip'
- task: PowerPlatformUnpackSolution@2
inputs:
SolutionInputFile: '$(Build.ArtifactStagingDirectory)/solution.zip'
SolutionTargetFolder: '$(Build.SourcesDirectory)/solutions/MyAppSolution'
- task: PowerPlatformChecker@2
inputs:
SolutionInputFile: '$(Build.ArtifactStagingDirectory)/solution.zip'
# Typical CD pipeline (to Production):
- task: PowerPlatformPackSolution@2
- task: PowerPlatformImportSolution@2
inputs:
Environment: '$(ProdEnvironmentUrl)'
SolutionInputFile: '$(Pipeline.Workspace)/solution.zip'
What are Power Platform Pipelines (in-product) vs Azure DevOps pipelines?
| Power Platform Pipelines | Azure DevOps / GitHub Actions | |
|---|---|---|
| Setup | Native in Admin Center | External DevOps tool required |
| Audience | Makers, citizen developers | Professional developers/DevOps |
| Customisation | Limited | Fully customisable |
| Testing | Manual | Automated test support |
| Best for | Simple solutions, maker-led deployments | Complex solutions, pro-code components, enterprise DevOps |
Tip: Most mature enterprise teams use Azure DevOps for complex solutions and Power Platform Pipelines for simpler maker-built apps. Both can coexist in the same tenant.
What is Solution Checker and why should it be part of every deployment pipeline?
Solution checker analyses a Power Platform solution against best practice rules and returns issues by severity (Critical, High, Medium, Low, Informational).
What it checks:
- Plugin and custom workflow code quality (deprecated APIs, missing error handling)
- JavaScript web resource issues (deprecated client API usage)
- Canvas app formula issues (delegation warnings, performance patterns)
- Solution structure issues (missing dependencies, invalid references)
# Run via CLI in pipeline:
pac solution check --path ./solution.zip \
--outputDirectory ./checker-results \
--rulesetId 0ad12346-e108-40b8-a956-9a373e549abb
# Gate deployment:
# Critical issues > 0 → fail pipeline, block deployment
# High issues > threshold → require manual approval
Tip: Solution checker as a mandatory CI quality gate is the difference between a governed and ungoverned ALM process. It catches technical debt before it reaches production.
What are connection references and environment variables and why are they critical for ALM?
Connection references: solution components acting as pointers to connections. Flows reference a Connection Reference instead of a hardcoded connection. After solution import, each environment's Connection Reference is updated to point to the appropriate connection.
Environment variables: solution components storing configuration values that differ per environment (API URLs, email addresses, SharePoint site IDs, feature flags).
WITHOUT Connection References/Env Variables (broken ALM):
→ Flow hardcodes connection to dev SharePoint site
→ Import to prod → flow still points to dev site
→ Must manually edit flow in each environment
→ Error-prone, time-consuming, not repeatable
WITH Connection References/Env Variables (proper ALM):
→ Flow references "SharePoint Connection Reference"
→ Import to prod → update Connection Reference to prod SharePoint
→ Set env variable: SiteURL = "https://prod.sharepoint.com/sites/app"
→ No flow edits needed — fully automated, environment-agnostic deployment
Critical: Not using Connection References and Environment Variables is the #1 cause of broken Power Platform deployments. Every solution component with environment-specific configuration MUST use these.
6. Monitoring, Auditing & Compliance
What analytics are available natively in Power Platform Admin Center?
| Report | Metrics |
|---|---|
| Power Apps analytics | Active users, app launches, sessions, errors, service performance |
| Power Automate analytics | Flow runs, success/failure rates, run durations, top flows |
| Copilot Studio analytics | Sessions, resolution rates, escalation rates per copilot |
| Capacity | Dataverse storage per environment, tenant-wide consumption |
| Connector usage | Which connectors are used, by which environments, top users |
For advanced analytics beyond the built-in reports, use the COE Starter Kit Power BI dashboard which aggregates inventory, usage, risk, and compliance data across the entire tenant.
How do you audit Power Platform activity for compliance?
Microsoft Purview (formerly Compliance Center):
- Power Platform operations are logged in the Microsoft 365 Unified Audit Log
- Auditable events: app creation/deletion, flow creation/deletion, environment creation, DLP policy changes, permission changes
- Accessible via Microsoft Purview compliance portal → Audit → Search
Power Platform Admin Center:
- Environment-level activity logs
- Admin activity logs (who changed DLP policies, who created environments)
Dataverse auditing:
- Record-level create/update/delete/access tracking
- Field-level change history
- Accessible via audit history on records or Dataverse Web API
What is the Power Platform for Admins connector and how is it used for governance automation?
The Power Platform for Admins connector provides actions for programmatic management of Power Platform resources — used extensively in COE Starter Kit flows.
Key actions:
Get Environments → list all environments
Create Environment → provision new environments
Delete Environment → remove environments
Get Apps as Admin → inventory all canvas apps
Get Flows as Admin → inventory all flows
Get Connectors as Admin → inventory all connectors
Suspend Flow as Admin → disable a flow remotely
Get DLP Policies → list all DLP policies
Common governance automation patterns:
→ Daily inventory sync (COE core)
→ Auto-suspend flows violating new DLP policy
→ Send weekly digest to makers of their resource usage
→ Auto-delete trial environments after 30 days
→ Alert when storage exceeds 80% of capacity
→ Notify when a new environment is created in the tenant
7. Scenario-Based Questions
Scenario: A new CISO wants to ensure no corporate data leaks to consumer services via Power Automate. What do you implement?
- Tenant-wide baseline DLP policy: move all Microsoft business connectors (SharePoint, Dataverse, Teams, Outlook, SQL Server, Azure services) to Business group. Move all consumer connectors (Gmail, Twitter, Facebook, personal OneDrive, Dropbox) to Non-business. Block high-risk connectors.
- Production environment DLP policy: additional restriction — only Microsoft-approved connectors in Business group. Block all non-Microsoft connectors.
- HTTP connector endpoint filtering: restrict HTTP action to only approved internal API endpoints.
- Connector action controls: on sensitive connectors like Dataverse, allow Read operations but restrict bulk Delete or Export actions.
- COE inventory monitoring: daily review of new connectors used across the tenant. Alert when a blocked connector is attempted.
- DLP violation reports: weekly report from COE to CISO showing suspended flows, violation trends, and remediation status.
Warning: Exclude the COE environment from the tenant DLP policy — it needs broader connector access for admin flows. Use an explicit exclusion list.
Scenario: Your organisation has 800 environments after 3 years of ungoverned Power Platform usage. How do you clean this up?
- Deploy COE Starter Kit — get full inventory of all 800 environments: owners, last activity, resource counts, storage consumption
- Categorise: Active (resources used < 90 days), Stale (90–180 days inactive), Abandoned (180+ days inactive)
- Owner notification campaign: automated email — "Your environment will be deleted in 30 days unless you confirm it is still needed"
- Stale environment archival: export all resources to solutions, back up Dataverse data, delete the environment
- Abandoned environment deletion: no owner response + no active resources → delete after backup
- Restrict new creation: simultaneously change tenant setting to admin-only environment creation — prevent new sprawl while cleaning up old
- Implement request process: going forward, all new environments require formal request with business justification approved by COE team
Tip: Tackle in waves — start with clearly abandoned environments (no activity, no resources), then stale. Never delete without backup and owner notification.
Scenario: A business-critical flow in production is owned by an employee who has left. How do you handle it?
Immediate remediation:
- Use Power Platform Admin role to reassign flow ownership to a service account via Admin Center → Flows → Edit owner
- Check the flow's connections — departed user's personal connections will be broken. Replace with service account connections or shared Connection References.
- Check if the flow uses the departed user's credentials (SharePoint, Outlook) — replace with service account or delegated credentials
- Test the flow end-to-end after ownership and connection transfer
Preventive measures:
- COE governance policy: all production flows must be owned by a service account or team, not an individual
- COE compliance process: quarterly audit of flow ownership — flag production flows owned by individuals
- IT offboarding checklist: include a Power Platform asset transfer step — reassign all flows/apps before account deletion
Critical: Flow connections tied to personal user accounts are the #1 cause of production outages when staff leave. This is a governance failure that COE ownership policies prevent.
Scenario: How do you set up a complete Dev → Test → Production ALM pipeline for a Power Apps solution?
Setup:
- Three environments: Dev (sandbox), Test (sandbox), Production. Separate DLP policies per environment.
- Dedicated service principal for pipeline authentication (not a personal admin account).
- Unmanaged solution in Dev. All components — app, flows, tables, connection references, environment variables.
- Azure DevOps repo with branch strategy: feature branches → main → release branches.
CI pipeline (on commit to feature branch):
- Export unmanaged solution from Dev environment
- Unpack to source files → commit to repo
- Run Solution Checker → fail build on Critical issues
CD pipeline — to Test (on merge to main):
- Pack as managed solution
- Import to Test environment
- Set Connection References and Environment Variables for Test
- Run automated smoke test flow
- Notify QA team for UAT
CD pipeline — to Production (manual trigger + approval gate):
- Same managed solution promoted from Test
- Required approval from business owner in Azure DevOps
- Import to Production
- Set Production Connection References and Environment Variables
- Post-deployment Teams notification to stakeholders
Scenario: How do you handle a maker who has built a production app in the Default environment using premium connectors?
Problem: Maker built a business-critical app in the Default environment using Dataverse — violating governance policy. Moving it is risky.
- Assess impact: use COE inventory to identify all users of the app, data connections, and dependencies
- Create a proper production environment: provision a new Production environment with correct DLP policy and security configuration
- Export the app as a solution: package the app, its flows, Dataverse tables, and connection references into a managed solution
- Migrate Dataverse data: use Data Export Service or Power Automate to copy data from Default to the new production environment's Dataverse
- Redirect users: update the app URL, update any embedded links, communicate the change to users with a transition period
- Delete or archive original: quarantine the Default environment copy first, verify all users are on the new app, then delete
- Update governance policy: document this scenario in the maker guidelines — new apps requiring Dataverse must request a proper environment from the start
8. Cheat Sheet — Quick Reference
DLP Policy Configuration Reference
Connector groups:
Business → approved for corporate data
Non-business → consumer/personal services
Blocked → cannot be used at all
Policy scope:
Tenant-wide → applies to ALL environments (with optional exclusions)
Environment → applies to specific environments only
Precedence → most restrictive policy wins
Key connectors to classify:
Business: SharePoint, Dataverse, Teams, Outlook, OneDrive for Business,
SQL Server, Azure Blob, Azure Service Bus, Azure Key Vault,
Power BI, Dynamics 365, Microsoft Forms
Non-business: Gmail, Twitter/X, Facebook, Dropbox, personal OneDrive,
Google Sheets, Slack (personal), Trello
Blocked: HTTP (without endpoint filtering), custom connectors
to unapproved endpoints
DLP violation outcome:
→ Existing flows: suspended immediately
→ New flows: cannot be saved/published
→ Owner notified by email with policy name and violation details
Environment Strategy Reference
Environment types and purposes:
Default → personal M365 productivity. Strict DLP. Remove Maker role.
Developer → individual maker sandbox. Free with Developer Plan.
Sandbox → team dev/test. Reset-able. Not for production data.
Production → live business data. Full backup. Strict access control.
COE/Admin → governance tools only. Permissive DLP for admin connectors.
Creation governance:
→ Restrict to admins only (tenant setting)
→ Request process: maker submits → manager approves → admin provisions
→ Mandatory fields: business owner, purpose, expected lifetime, data classification
Lifecycle:
90 days inactive → automated owner notification
120 days inactive → quarantine (access suspended)
150 days inactive → deletion (with backup)
Trial environments → auto-expire after 30 days
ALM Pipeline Checklist
Solution setup:
☐ Custom publisher prefix (not 'new_')
☐ All components in solution
☐ Connection References for all connectors
☐ Environment Variables for all env-specific config
☐ No hardcoded connection strings or URLs
CI pipeline:
☐ Export solution from Dev
☐ Unpack to source files
☐ Commit unpacked files to Git repo
☐ Run Solution Checker
☐ Fail on Critical issues
CD to Test:
☐ Pack managed solution
☐ Import to Test environment
☐ Configure Connection References
☐ Set Environment Variable values
☐ Run smoke test / automated tests
☐ Notify QA for UAT
CD to Production:
☐ Manual approval gate (business owner sign-off)
☐ Import same managed solution from Test
☐ Configure Production Connection References
☐ Set Production Environment Variable values
☐ Post-deployment notification
☐ Monitor for errors in first 24 hours
COE Starter Kit — Key Components
Core module:
→ Daily inventory sync (flows, apps, envs, makers, connectors)
→ Admin Power BI dashboard
→ Environment overview report
Governance module:
→ Compliance flow (maker emails, grace periods, quarantine, delete)
→ Environment request and approval process
→ Developer environment provisioning automation
→ Orphaned resource identification and cleanup
→ DLP violation reporting
Nurture module:
→ Maker onboarding welcome email automation
→ App gallery / showcase
→ Training resource hub
→ Maker community management
→ Hackathon toolkit
Admin connector actions used:
Get/List Environments, Apps, Flows, Connectors, Makers
Suspend Flow as Admin
Delete Environment
Add/Remove Environment Maker role
Governance Maturity Model
Level 1 — Reactive (no governance):
→ Default environment used for everything
→ No DLP policies
→ No inventory visibility
→ Issues discovered only when things break
Level 2 — Basic (foundational):
→ Tenant-wide DLP policy applied
→ Environment creation restricted to admins
→ COE Starter Kit deployed (inventory only)
→ Maker onboarding process defined
Level 3 — Managed (operational):
→ Environment strategy implemented (dev/test/prod)
→ DLP policies per environment type
→ COE governance module running (compliance emails)
→ ALM pipeline for key solutions
→ Regular environment audits
Level 4 — Optimised (mature):
→ Full COE with champions network
→ Automated environment lifecycle management
→ Solution Checker in CI/CD pipelines
→ Connection References + Env Variables everywhere
→ Monthly governance reviews with metrics
→ Risk scoring and remediation tracking
→ Fusion team model (makers + pro devs + IT)
Top 10 Tips
- DLP = connector grouping, not content scanning — DLP in Power Platform prevents connectors from being combined, not scanning message content like M365 DLP. Clarify this distinction confidently.
- Tenant policy wins over environment policy — environment policies can only be more restrictive, never more permissive. The tenant baseline always applies.
- Restrict environment creation first — this is the single most impactful governance action. Mention it in every environment sprawl question.
- Default environment is highest risk — every licensed user is a maker there by default. Always recommend removing the Maker role and applying strict DLP.
- Connection References are mandatory for ALM — hardcoded connections are the #1 cause of broken deployments. Mentioning this signals real deployment experience.
- COE Starter Kit is the governance answer at scale — know its three modules (Core, Governance, Nurture) and what each does. It is the expected answer to "how do you govern Power Platform."
- Service accounts for production flows/apps — never personal user accounts.
- Solution Checker in CI pipelines — quality gate that catches technical debt before production. A maturity signal in any ALM discussion.
- DLP violations suspend existing flows — a new policy change immediately impacts running flows. Always audit before applying a new policy.
- Governance vs adoption balance — Governance that blocks legitimate use is a failure just as much as no governance at all. The goal is "managed self-service."
No comments:
Post a Comment