🗺️ Course Module Map

🏠 Module 1: Power Platform Admin Center Overview

The Power Platform Admin Center at admin.powerplatform.microsoft.com is the central governance hub for all Power Platform workloads — Power Apps, Power Automate, Power BI, Power Pages, and Copilot Studio. It provides visibility into all environments across the tenant, all DLP policies, capacity consumption, and analytics — giving administrators the controls needed to govern citizen development at scale.

Power Platform Admin Roles

Managed Environments — 2025–2026 Key Feature

🌍 Module 2: Environments

Environments are the fundamental containers in Power Platform — they hold apps, flows, Dataverse databases, connections, and chatbots. Every Power Platform resource exists in exactly one environment. Organisations typically implement an environment strategy separating Development, Test/UAT, and Production environments, plus a Default environment for unmanaged citizen development.

Environment Types

# Install Power Apps Admin PowerShell modules (run once)
Install-Module Microsoft.PowerApps.Administration.PowerShell -Force -AllowClobber
Install-Module Microsoft.PowerApps.PowerShell -Force -AllowClobber

# Connect to Power Platform
Add-PowerAppsAccount

# Get all environments across the tenant
Get-AdminPowerAppEnvironment | Select-Object DisplayName,EnvironmentName,Location,EnvironmentType,IsDefault | Sort-Object DisplayName | Format-Table -AutoSize

# Create a new Production environment with Dataverse in Europe
New-AdminPowerAppEnvironment `
  -DisplayName "Contoso Production" `
  -Location "europe" `
  -EnvironmentSku Production `
  -ProvisionDatabase `
  -CurrencyName "GBP" `
  -LanguageName 1033
Write-Host "Production environment created."

# Get the Default environment and restrict maker access
$DefaultEnv = Get-AdminPowerAppEnvironment | Where-Object {$_.IsDefault -eq $true}
Set-AdminPowerAppEnvironmentRoleAssignment `
  -EnvironmentName $DefaultEnv.EnvironmentName `
  -RoleName EnvironmentMaker `
  -PrincipalType Group `
  -PrincipalObjectId "approved-makers-security-group-id"

🚫 Module 3: DLP Policies for Power Platform

Data Loss Prevention (DLP) policies in Power Platform control which connectors can be used together in the same app or flow. Every connector is placed in one of three tiers: Business, Non-Business, or Blocked. Connectors in Business and Non-Business tiers cannot be combined in the same app or flow — this prevents, for example, SharePoint data (Business) from flowing into a personal Gmail connector (Non-Business).

Power Platform DLP Policy Concepts

Add-PowerAppsAccount

# Get all existing DLP policies
Get-DlpPolicy | Select-Object DisplayName,PolicyName,CreatedTime,LastModifiedTime | Format-Table -AutoSize

# Get connector classifications in a specific DLP policy
$Policy = Get-DlpPolicy | Where-Object {$_.DisplayName -eq "Contoso Tenant DLP Policy"}
Get-DlpPolicyConnectorConfigurations -PolicyName $Policy.PolicyName |
  Select-Object ConnectorId,GroupName |
  Format-Table -AutoSize

# Create a new tenant-wide DLP policy
New-DlpPolicy -DisplayName "Contoso Standard DLP Policy" -EnvironmentType AllEnvironments
$NewPolicy = Get-DlpPolicy | Where-Object {$_.DisplayName -eq "Contoso Standard DLP Policy"}

# Classify Microsoft connectors to Business tier
$BusinessConnectors = @(
  "/providers/Microsoft.PowerApps/apis/shared_sharepointonline",
  "/providers/Microsoft.PowerApps/apis/shared_teams",
  "/providers/Microsoft.PowerApps/apis/shared_commondataservice",
  "/providers/Microsoft.PowerApps/apis/shared_office365outlook"
)
foreach ($ConnectorId in $BusinessConnectors) {
  Set-DlpPolicyConnectorGrouping `
    -PolicyName $NewPolicy.PolicyName `
    -ConnectorId $ConnectorId `
    -GroupName hbi
  Write-Host "Set Business tier: $ConnectorId"
}

💻 Module 4: Power Apps Governance

Power Apps governance focuses on maintaining visibility and control over the apps being built across your organisation’s environments — identifying orphaned apps (makers who have left), apps with too many users sharing them informally, apps using non-approved connectors, and apps in the Default environment that should be migrated to governed environments.

Add-PowerAppsAccount

# Export complete Power Apps inventory across all environments
Get-AdminPowerApp |
  Select-Object DisplayName,AppName,Owner,EnvironmentName,LastModifiedTime |
  Sort-Object LastModifiedTime -Descending |
  Export-Csv -Path "PowerAppsInventory.csv" -NoTypeInformation
Write-Host "Power Apps inventory exported."

# Get all apps in the Default environment (often ungoverned)
$DefaultEnvName = (Get-AdminPowerAppEnvironment | Where-Object {$_.IsDefault -eq $true}).EnvironmentName
Get-AdminPowerApp -EnvironmentName $DefaultEnvName |
  Select-Object DisplayName,Owner,LastModifiedTime |
  Sort-Object LastModifiedTime |
  Format-Table -AutoSize

# Find apps shared org-wide (shared with Everyone — review urgently)
Get-AdminPowerAppRoleAssignment -EnvironmentName $DefaultEnvName |
  Where-Object {$_.PrincipalType -eq "Tenant"} |
  Select-Object AppName,RoleName,PrincipalDisplayName |
  Format-Table -AutoSize

⚡ Module 5: Power Automate Governance

Power Automate governance ensures that automated flows across the organisation are using approved connectors, are owned by active users (not departed employees), are not running undetected processes that exfiltrate data, and that Robotic Process Automation (RPA) desktop flows are properly licensed and monitored.

Add-PowerAppsAccount

# Export complete flow inventory across all environments
Get-AdminFlow | Select-Object DisplayName,FlowName,CreatedBy,EnvironmentName,Enabled,LastModifiedTime |
  Sort-Object LastModifiedTime -Descending |
  Export-Csv -Path "PowerAutomateFlowInventory.csv" -NoTypeInformation
Write-Host "Flow inventory exported."

# Get flow run history for a specific flow
$EnvName = "your-environment-name"
$FlowName = "flow-guid-here"
Get-AdminFlowRun -EnvironmentName $EnvName -FlowName $FlowName |
  Select-Object StartTime,EndTime,Status,TriggerType |
  Sort-Object StartTime -Descending -First 20 |
  Format-Table -AutoSize

# Change flow owner when original owner has left the org
Set-AdminFlowOwnerRole -EnvironmentName $EnvName -FlowName $FlowName `
  -RoleName Owner `
  -PrincipalType User `
  -PrincipalObjectId "new-owner-user-object-id"
Write-Host "Flow owner updated."

# Disable a policy-violating flow
Disable-AdminFlow -EnvironmentName $EnvName -FlowName $FlowName
Write-Host "Flow disabled."

📊 Module 6: Power BI Admin

Power BI administration is managed via the Power BI Admin Portal (app.powerbi.com → Settings → Admin portal) and also surfaces some settings in the Power Platform Admin Center. Key admin responsibilities include governing tenant settings, managing workspaces, controlling data export capabilities, and managing Premium/Fabric capacity.

Key Power BI Admin Portal Settings

🌐 Module 7: Power Pages Administration

Power Pages (formerly Power Apps Portals) enables organisations to build externally-facing websites connected to Dataverse — citizen portals, partner portals, customer self-service sites — with authentication, forms, and Dataverse integration, without traditional web development. Admin responsibilities include site capacity, authentication configuration, WAF, and lifecycle management.

Power Pages Admin Key Tasks

🔐 Module 8: Connectors & Custom Connectors

Connectors are the integration bridges between Power Platform and external services. There are 1,000+ standard connectors (built by Microsoft and third-party publishers) and the ability to create custom connectors for proprietary REST APIs. Connector governance is the primary mechanism for controlling data flow in Power Platform — via DLP policies that classify connectors into Business/Non-Business/Blocked tiers.

Connector Tiers — Common Classifications

📚 Module 9: CoE Starter Kit

The Center of Excellence (CoE) Starter Kit is a free, open-source collection of Power Platform components built by Microsoft that provides the governance infrastructure most organisations need — a full inventory of all apps, flows, and makers, an automated compliance process that contacts makers and requests justification for their solutions, and adoption dashboards that track Power Platform usage trends.

CoE Starter Kit Components

⚖️ Module 10: Capacity & Licensing

Power Platform capacity management is one of the most complex areas of administration — it involves both per-user licences (for makers and users) and tenant-level capacity pools (for Dataverse storage, API calls, and RPA bot usage). Monitoring capacity prevents unexpected service throttling or overage charges.

Power Platform Capacity Types

📊 Module 11: Analytics & Monitoring

Add-PowerAppsAccount

# Get connector usage across all environments (ranked by usage)
Get-AdminPowerAppConnectionReferences |
  Select-Object ConnectorId,ConnectorDisplayName,AppName,EnvironmentName |
  Group-Object ConnectorDisplayName |
  Select-Object Name,Count |
  Sort-Object Count -Descending |
  Format-Table -AutoSize

# Export all connections inventory (user credential connections)
Get-AdminPowerAppConnection | Select-Object DisplayName,ConnectorName,CreatedBy,EnvironmentName |
  Sort-Object ConnectorName |
  Export-Csv -Path "ConnectionsInventory.csv" -NoTypeInformation

# Get Dataverse storage per environment
Get-AdminPowerAppEnvironment | ForEach-Object {
  $S = Get-AdminPowerAppEnvironmentCapacity -EnvironmentName $_.EnvironmentName
  [PSCustomObject]@{
    Environment = $_.DisplayName
    DatabaseMB  = $S.DatabaseCapacityMB
    FileMB      = $S.FileCapacityMB
    LogMB       = $S.LogCapacityMB
  }
} | Sort-Object DatabaseMB -Descending | Format-Table -AutoSize

🎓 Module 12: PL-900 / PL-200 Certification Alignment

💡 Best Practices Summary

• Create a dedicated CoE environment for the CoE Starter Kit — never install CoE in the Default environment; it uses significant Dataverse storage and should be isolated from citizen developer activity
• Deploy the CoE Starter Kit before rolling out Power Platform broadly — you need inventory visibility from day one to prevent uncontrolled sprawl in the Default environment
• Block the HTTP connector in your tenant-wide DLP policy — it is the primary data exfiltration risk; only allow it in specific developer environments with IT oversight
• Set up a default environment strategy before enabling Power Platform: restrict the Default environment to approved makers via a security group; create separate Sandbox environments for development and Production environments for live apps
• Enable Managed Environments for your Production environments — the sharing limits and usage insights emails pay for themselves by preventing ungoverned app sprawl
• Monitor Dataverse storage monthly — log storage accumulates silently; schedule regular audit log purges and review large tables for unnecessary data retention
• Implement solution-aware flows and apps from the start — resources built inside solutions can be deployed across environments using pipelines; resources built outside solutions cannot be easily migrated
• Review the connector inventory quarterly using CoE dashboards — new connectors added to the platform are automatically classified as Non-Business in existing DLP policies; review and reclassify as needed

📚 References

• 🔗 Power Platform Admin Documentation — Microsoft Learn
• 🔗 PL-900: Power Platform Fundamentals — Microsoft Learn
• 🔗 PL-200: Power Platform Functional Consultant — Microsoft Learn
• 🔗 CoE Starter Kit Documentation — Microsoft Learn
• 🔗 DLP Policies for Power Platform — Microsoft Learn
• 🔗 Power Platform Admin Center — admin.powerplatform.microsoft.com