ALM for Power Automate: solutions, environments and CI/CD with Azure DevOps

Application Lifecycle Management (ALM) in the Power Platform is often neglected, resulting in flows "directly in production", with no version control and impossible to roll back. ALM best practices prevent this problem.

Environment structure

Recommended environments:
  DEV   → individual development, fake data
  TEST  → integration testing, prod-like data
  PROD  → managed solutions only, no direct editing

Solutions — the deployment unit

// Create a solution in the DEV environment:
make.powerapps.com → Solutions → New Solution
  Publisher: BConcepts (prefix: bcpt)
  Version: 1.0.0.0

// Add existing flows to the solution:
Add existing → Cloud flow
// IMPORTANT: only flows inside solutions can be exported/imported correctly

Export and import manually

// DEV → TEST (unmanaged solution for testing)
Export → Unmanaged → bconcepts_Flows_1.0.0.0.zip

// TEST → PROD (managed solution — not editable in PROD)
Export → Managed → bconcepts_Flows_1.0.0.0_managed.zip
Import into the PROD environment

CI/CD with Azure DevOps and the Power Platform CLI

# Azure DevOps pipeline YAML
trigger:
  - main

steps:
  - task: PowerPlatformToolInstaller@2

  - task: PowerPlatformExportSolution@2
    inputs:
      authenticationType: PowerPlatformSPN
      PowerPlatformSPN: 'Dev-SPN'
      SolutionName: 'BConcepts_Flows'
      SolutionOutputFile: $(Build.ArtifactStagingDirectory)/BConcepts_Flows.zip

  - task: PowerPlatformImportSolution@2
    inputs:
      authenticationType: PowerPlatformSPN
      PowerPlatformSPN: 'Prod-SPN'
      SolutionInputFile: $(Build.ArtifactStagingDirectory)/BConcepts_Flows_managed.zip
      ConvertToManaged: true

Conclusion

ALM in the Power Platform is not complex — it requires the discipline of always working inside solutions, using separate environments and automating deployment with pipelines. The initial setup investment saves hours of debugging in production.