Solution Limitations¶

This document explains the technical limitations of Power Platform pipelines governance automation and provides alternatives for each constraint.

Summary: Full automation of pipeline governance cleanup is not possible due to Power Platform's architecture. This solution provides partial automation where available and documented manual procedures for the rest.

Critical Limitations¶

1. `pac pipeline link` Command Does NOT Exist¶

What the documentation originally claimed:

# THIS COMMAND DOES NOT EXIST:
pac pipeline link --environment-id <target-env-id> --host-environment-id <host-env-id>

Reality: The Power Platform CLI (pac) has only two pipeline-related commands: - pac pipeline list - Lists pipelines in an environment - pac pipeline deploy - Triggers a pipeline deployment

There is no CLI command to link or force-link environments to a pipelines host.

Source: PAC CLI Pipeline Reference

Alternative: Manual UI in Deployment Pipeline Configuration app. See Portal Walkthrough.

2. DeploymentPipeline Table Cannot Be Queried via "List rows"¶

What the documentation originally claimed:

Use Power Automate "List rows" action to query the DeploymentPipeline table.

Reality: The DeploymentPipeline table is a system-managed table that is NOT exposed to standard Dataverse query operations in Power Automate. Attempting to use "List rows" with this table will fail or return no results.

Why: Microsoft restricts direct query access to pipeline system tables to prevent interference with the pipeline execution engine.

What IS available: - Pipeline trigger events - Power Automate can respond to deployment lifecycle events - Direct Dataverse API - With appropriate permissions, advanced users can query via Web API - Deployment Pipeline Configuration app - UI access for administrators

Alternative: Use pipeline triggers (OnDeploymentCompleted, etc.) for event-based monitoring. See Automation Guide.

3. Cannot Identify Pipelines Host Association via API¶

What CAN be automated: You can detect whether an environment has pipelines using:

pac pipeline list --environment <env-id>

Note: The pac pipeline list command does not support --json output. The script parses text output to detect pipeline presence.

This returns pipelines that deploy TO the environment (as a target stage). Use the -ProbePipelines switch in Get-PipelineInventory.ps1 to automate this check across all environments.

What CANNOT be automated: Determining which host environment owns/hosts the pipeline configuration. The association is implicit - a pipeline belongs to whichever environment's Dataverse database contains it. There is no field in the DeploymentPipeline table (or related tables) that indicates which host environment the pipeline belongs to.

Why this matters: You cannot programmatically determine "which environments have pipelines hosted outside the designated host" because: 1. You can't query the DeploymentPipeline table via standard APIs 2. Even if you could, there's no "host environment ID" field 3. The pipeline-to-host relationship is implicit (the host is where the pipeline record exists)

Alternative for host identification: 1. List all environments via PowerShell/PAC CLI 2. Use -ProbePipelines to identify environments with pipelines configured 3. Manually check each environment with pipelines in the Deployment Pipeline Configuration app to see which host they're linked to 4. Build your own tracking table/spreadsheet

4. Force-Link Is UI-Only¶

The problem: Associating (or force-linking) an environment to a pipelines host can ONLY be done through the Deployment Pipeline Configuration model-driven app UI. There is no: - API endpoint - CLI command - Power Automate action - PowerShell cmdlet

Why: Microsoft designed force-linking as an intentional administrative action with confirmation dialogs to prevent accidental breaking of existing pipeline configurations.

Alternative: Document a manual procedure and train administrators. See Portal Walkthrough.

5. Platform Host Cannot Be Governed Directly¶

The problem: Organizations using Microsoft's automatic platform host (the tenant-wide default for personal pipelines) cannot directly govern it. The platform host: - Is infrastructure-managed and not visible as a separate environment - Does not show "Power Platform Pipelines" in development environments' Dynamics 365 apps list - Has limited administrative controls compared to custom hosts

Alternative: Create a custom pipelines host and Force Link all environments to it. Optionally, set your custom host as the "default custom pipelines host" to override the platform host for new makers.

See: https://learn.microsoft.com/en-us/power-platform/alm/set-a-default-pipelines-host

6. Force Link Controls Environment-Host Association¶

Important distinction: - Force Link changes which host an environment is associated with - This affects BOTH deployments FROM and TO that environment (environments can only be associated with ONE host) - Force Link does NOT prevent users from CREATING new pipeline hosts in other environments

Can users still CREATE personal pipelines after you Force Link environments? YES. Any user with admin rights on an environment with Dataverse can install Power Platform Pipelines and create their own host. However, pipelines in that personal host cannot deploy to or from environments you've Force Linked to your designated host.

Full prevention requires Force Link PLUS restricting the "Deployment pipeline default" role in your custom host (controls who can create personal pipelines when your host is set as the default).

See: https://learn.microsoft.com/en-us/power-platform/alm/custom-host-pipelines

7. Backup, Recovery, and Cascade Effects¶

Understanding what happens during force-link operations helps prevent data loss and plan for recovery scenarios.

What happens when you Force Link an environment:

Effect	Description
Old pipelines orphaned	Pipelines in the old host can no longer deploy to the force-linked environment
Old definitions retained	Pipeline configurations remain in the old host (not deleted)
Target solutions unaffected	Solutions already deployed to the environment are not changed
History retained	Pipeline run history remains in the old host environment

What happens if the host environment is deleted:

Effect	Recovery Possible?
All pipelines permanently deleted	No - pipeline configurations cannot be recovered
Deployment stage configurations lost	No
Pipeline run history lost	No
Linked environments become unlinked	Yes - can link to a different host
Solutions in target environments	Unaffected - solutions remain in place

Recovery options:

Force-link to different host: If your host is compromised, you can force-link environments to a new host
No "unlink" operation: Environments must always be linked to exactly one host
No export/backup: Pipeline configurations cannot be exported or backed up to files

FSI Recommendation:

Do not delete the old host environment until your retention period expires (typically 7 years for financial services). The old host contains: - Pipeline deployment history (when, who, what was deployed) - Pipeline configuration history (how pipelines were configured) - Audit trail for compliance evidence

8. Managed Environment Licensing Implications¶

Starting February 2026, Microsoft requires all pipeline target environments to be Managed Environments.

What this means:

Pipeline targets (environments that receive deployments) must be Managed Environments
This is a prerequisite you must address manually
Microsoft does not automatically convert environments or provision licenses

Licensing considerations:

Consideration	Impact
Premium licensing	Managed Environments require Power Platform premium licensing for certain features
User licenses	Users and apps in Managed Environments may need upgraded licenses
Capacity	Managed Environments may consume additional capacity
Add-on availability	Some Managed Environment features require add-on licenses

Before enabling Managed Environments:

Review current licenses in Microsoft 365 Admin Center
Identify which users/apps will be affected
Estimate licensing cost impact
Budget for additional licenses if needed

Note: This solution does not automate license provisioning or environment conversion. Address licensing manually before force-linking.

See Microsoft Learn: Managed Environments for licensing details.

What CAN Be Automated¶

Despite the limitations above, several governance tasks can be automated:

Task	Method	Notes
List all environments	PowerShell + PAC CLI	Uses `pac admin list --json`
Export environment metadata	PowerShell	Type, URL (IsManaged requires portal check)
Detect pipeline presence	PowerShell + PAC CLI	Uses `pac pipeline list` (text parsing, no --json)
Send notification emails	Microsoft Graph API	Supports delegated and application permissions
Post Teams alerts	Power Automate	Full automation
Monitor deployments	Power Automate triggers	Event-based only
Track compliance status	Custom Dataverse table	Manual updates required

Microsoft Documentation Sources¶

These are the authoritative sources confirming the limitations:

PAC CLI Pipeline Commands¶

URL: https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/pipeline

Available commands: - pac pipeline list - List pipelines - pac pipeline deploy - Deploy a pipeline

Not available: link, create, delete, configure

Extend Pipelines in Power Platform¶

URL: https://learn.microsoft.com/en-us/power-platform/alm/extend-pipelines

What's documented: - Pipeline extensibility through Dataverse triggers - Pre and post deployment customization - Event-based integration

What's NOT documented: Querying pipeline tables, programmatic linking

Set Up Custom Host for Pipelines¶

URL: https://learn.microsoft.com/en-us/power-platform/alm/custom-host-pipelines

Key statement:

"Link development environments to the pipelines host using the Deployment Pipeline Configuration app"

Implication: The documentation only describes UI-based linking, confirming no API exists.

Setting Customer Expectations¶

When implementing this solution, communicate these realities:

What This Solution Provides¶

Capability	Delivery
Discovery	PowerShell scripts export environment list
Communication	Automated email notifications to owners
Tracking	Custom Dataverse table or Excel spreadsheet
Monitoring	Trigger-based alerts for deployment events
Procedures	Documented manual steps for force-linking

What This Solution Does NOT Provide¶

Capability	Reality
Automated enforcement	Admin must manually force-link each environment
Self-service cleanup	Makers cannot self-migrate pipelines
Pipeline inventory export	Cannot query DeploymentPipeline table
Scheduled force-link	Force-link is always manual
API-based compliance check	Must use UI or manual verification

Recommended Customer Communication¶

Include this in your governance communications:

Pipeline Governance Notice

Our organization is consolidating deployment pipelines to a centralized host.

Automated steps: - You will receive email notification before any changes - 30-60 day notice period for migration

Manual steps (performed by admins): - Environments will be force-linked to the corporate host - This action cannot be undone without admin intervention

Your action required: - Migrate pipelines to the corporate host, OR - Request an exemption with business justification

Future Considerations¶

Microsoft's Power Platform roadmap may address some limitations:

Potential Future Capabilities¶

Capability	Status	Notes
API for pipeline management	Not announced	Would enable full automation
CLI force-link command	Not announced	Would enable scripted enforcement
Query support for system tables	Unlikely	Security/stability concerns
Bulk environment linking	Not announced	Would speed up migrations

Workaround Strategies¶

Until Microsoft provides APIs:

Azure Automation + UI Automation
Use browser automation (Selenium, Playwright) to script the UI
High maintenance burden, brittle to UI changes
Not recommended for production
Dataverse Web API Direct Access
With System Administrator role, may be able to query/modify system tables
Unsupported, may break with updates
Not recommended
Microsoft Support Engagement
For large-scale migrations, engage Microsoft support
They may have internal tools for bulk operations
Recommended for 100+ environment migrations

Summary¶

Limitation	Severity	Workaround
No `pac pipeline link`	Critical	Manual UI procedure
Can't query DeploymentPipeline	Critical	Use triggers only
No host association field	High	Manual verification
Force-link is UI-only	High	Documented procedure
Can't detect host for pipelines	Medium	Use `-ProbePipelines` + manual host verification

Bottom line: This solution automates what can be automated (discovery, notification, monitoring) and provides clear documentation for the manual steps that remain unavoidable.