What it does

Everything an admin does in the Power Platform admin centre has a programmable equivalent. Microsoft now develops these API-first: new capability lands in the Power Platform API, then flows out to the SDKs, CLI, PowerShell cmdlets and connectors.

Key facts

• There are two planes and they don't overlap. The customer management plane — environments, tenant settings, billing policies, capacity — is the Power Platform API. The customer data plane — rows inside an environment — is the Dataverse Web API.
• The environment-management portion of the Power Platform API is the generally available 2020-10-01 version, still widely referred to as the BAP API.
• Client options, roughly in order of increasing capability: the Power Platform for Admins V2 connector for Power Automate and Logic Apps; the .NET SDK (Microsoft.PowerPlatform.Management on NuGet); the Python SDK (powerplatform-management on PyPI); the Power Platform CLI; and the PowerShell cmdlets.
• PowerShell sign-in is Add-PowerAppsAccount -Endpoint prod, interactively or with a service principal using tenant ID, client ID and secret or certificate.
• Tenant admin, Power Platform administrator or Dynamics 365 Service Administrator roles can use the admin cmdlets without a Power Apps plan — but they must sign in to the Power Platform admin centre at least once first, or the cmdlets fail with an authorisation error.
• Power Platform administrator or Dynamics 365 administrator is required to search another user's resources. Environment admins only see environments they have permissions on.
• Some settings are PowerShell-only in practice — the tenant's preferred environment location, set through Set-TenantSettings, is a good example.
• Backup retention for production Managed Environments is settable through Set-AdminPowerAppEnvironmentBackupRetentionPeriod and readable through Get-AdminPowerAppEnvironment.
• Deleted environments can be recovered with Recover-AdminPowerAppEnvironment within seven days, or up to 28 days for production environments carrying Dynamics 365 applications.
• RBAC in the admin centre doesn't cover the whole API yet. As of September 2026 role-based access control applies to all Power Pages endpoints, all environment-management endpoints except List Environments for User and Get Environment by ID for User, and all governance endpoints except the cross-tenant connection report endpoints. Everything else still falls back to the tenant-wide admin roles.
• Environment lifecycle endpoints — copy, backup, restore, failover — went GA in the public cloud in August 2026. Sovereign clouds are scheduled for 1 December 2026, not before.
• The CLI covers environment lifecycle, authentication, solution packaging, Power Pages and code components — it's the developer-side tool rather than the tenant-governance one.

When to use / skip

Automate the things you'd otherwise do badly by hand: environment provisioning with the right security group, naming and region; capacity and inventory reporting; DLP policy audits; the environment refresh cycle. Anything you do more than monthly across more than a handful of environments is worth scripting. What isn't worth it is automating a process the client hasn't agreed yet — plenty of tenants have a beautifully scripted provisioning pipeline sitting on top of a governance model nobody signed off. Start with read-only inventory scripts, get agreement on what the data says, then automate the write operations.

Configuration decisions

• Which client to standardise on. The connector for anything a business user should be able to trigger, PowerShell for admin scripting, the SDKs where you need real error handling and typing.
• Service principal versus interactive authentication, and where the secret or certificate lives. Anything running unattended needs a principal.
• Which admin roles the automation identity holds, and whether that's Power Platform administrator across the tenant or narrower environment-level access.
• Whether environment provisioning is a self-service request pipeline or an admin-run script, and what the approval step is.
• Where automation output goes — a Dataverse table, a Log Analytics workspace, a SharePoint list — because reporting that lives only in a console isn't governance.

Gotchas

• The "sign in to the admin centre once first" prerequisite catches everyone at least once. The error looks like a permissions problem and isn't.
• New capability appears in the API before the cmdlets and connectors catch up, so a feature you can see in the portal may have no PowerShell equivalent yet. Check the API reference before assuming it can't be done.
• Environment history is deleted with the environment, so scripted deletions need to log what they did somewhere durable if you ever want to answer "who removed this".
• Setting backup retention through PowerShell on anything other than a production Managed Environment silently has no effect — the value is accepted and the seven-day default still applies.
• Environment group rules override environment-level settings. A script that sets a value directly can be quietly outranked.
• Scoping the automation identity with RBAC instead of a tenant-wide admin role sounds like the right answer in a security review, and then you find the specific endpoint your script needs is one of the ones RBAC doesn't cover yet. Check the supported-endpoint list before you promise least privilege — the gaps are named, not implied.
• A sovereign-cloud client can't have the scripted copy/backup/restore pipeline the public-cloud client just got. Worth saying out loud in December 2026 planning rather than discovering it during the build.

Consultant notes

• Deliver the inventory script before the governance workshop. Nothing moves a tenant governance conversation faster than a spreadsheet of every environment, owner, region and capacity figure.
• Warn clients that the API-first model means documentation lags capability. Point their platform team at the versioning and what's-new pages as a standing item.
• Keep the automation identity's permissions in the security model documentation. It's a Power Platform administrator on a service principal and it will come up in the first security review.
• Where a client's IT function already runs Azure DevOps or GitHub Actions, put the environment lifecycle scripts there rather than on someone's laptop. The laptop version always becomes the single point of failure.

---

Worth revisiting once more management-plane capability lands in the Power Platform API, when RBAC endpoint coverage widens, or after the 1 December 2026 sovereign-cloud date.