Levelling Up Your Power Platform Workflow with the PAC CLI

Introduction

If you have been building on Power Platform for some time, the maker portal is probably where most of your time is spent. For spinning up apps, building out flows, and getting started on new projects it does the job well. However, as your solutions grow in complexity and you start thinking about things like multi-environment deployments, collaborating with other developers, or just having a more reliable workflow — the portal starts to show its limitations.  
 
This is where the Power Platform CLI (PAC CLI) comes in. It is a free, cross-platform command-line tool from Microsoft that gives you a scriptable interface for most things you would do through the maker portal, plus quite a few things the portal simply cannot do. You can install it through the Power Platform Tools extension in VS Code, or as a .NET tool with dotnet tool install --global Microsoft.PowerApps.CLI.Tool.  
 
In this article, we will go through three key benefits of the PAC CLI that make it worth adding to your workflow.  

1. pac solution unpack — Your Solutions in Source Control

By default, the Power Platform exports solutions as .zip files and canvas Power Apps appear as .msapp files which are essentially .zip. This works fine for moving solutions between environments, but when it comes to source control it is essentially useless. A solution zip is a binary blob — you cannot meaningfully diff it, merge it, or read through it line by line.  
 
pac solution unpack is the command that changes this. It extracts your zip into a folder structure of XML, YAML, and JSON files with one file per component. Canvas apps come out as readable YAML, flows as JSON, and everything else as plain text that git can actually work with.

pac solution unpack --zipfile mysolution.zip --folder ./src 

This unlocks a number of workflows that were not really possible before:

1. Real git diffs. When two developers make changes to the same canvas app on separate branches, you can three-way merge it like any other source file. No more "whoever exports last wins."
2. Meaningful code reviews. Pull requests now show exactly what changed — a form layout, a business rule, a flow step. You can review by reading rather than clicking around the maker portal.
3. AI-assisted documentation. You can paste an unpacked canvas app's YAML or a flow's JSON directly into an AI tool and ask it to document every screen, formula, and navigation path. What used to take days of manual effort can be done in minutes.
4. Proper audit history. When a client asks what changed in a specific release, a single git diff between tags will give you the answer.

 
When you are ready to re-import, you simply pack it back up:

pac solution pack --folder ./src --zipfile mysolution.zip

This pair of commands is the foundation that everything else — proper ALM, branching strategies, automated testing, AI tooling — gets built on top of. If you only take away one PAC CLI command from this article, make it this one.  

2. pac admin — Environment Lifecycle from Your Terminal

Provisioning a new Power Platform environment through the admin portal is a repetitive process. You navigate to the admin center, fill out a form, wait for it to provision, come back and set up Dataverse, import your base solutions, and configure your users. It takes time and it is easy for environments to end up configured inconsistently each time.  
 
pac admin create handles all of this from your terminal. Worth noting — the --currency and --language flags are what signal to the API to provision a Dataverse database in the environment. Leave them out and you get a bare environment with no Dataverse.

pac admin create `
  --name "Devela Dev" `
  --region canada `
  --type Sandbox `
  --currency CAD `
  --language English

Some other pac admin commands worth keeping handy:

• pac admin list — view all environments in your tenant with type, URL, and admin in one place
• pac admin copy — clone an environment without needing to raise a ticket
• pac admin reset — wipe a sandbox back to a clean state
• pac admin backup — take a manual backup before a risky deployment

The real value here is that all of these commands are scriptable. Wrapping them in a PowerShell script means that provisioning a new client environment becomes a one-line invocation:

param([string]$Client)

# Provision dev + prod environments
pac admin create --name "$Client-dev"  --type Sandbox    --region canada --currency CAD --language English
pac admin create --name "$Client-prod" --type Production --region canada --currency CAD --language English

# Import the base solution into each
pac auth select --name "$Client-dev";  pac solution import --path ./base-solution.zip
pac auth select --name "$Client-prod"; pac solution import --path ./base-solution.zip

Onboarding a new client becomes .\provision.ps1 -Client acme-brokerage instead of an afternoon of clicking. Two scenarios where this really pays off:

• Multi-tenant consulting. Every client gets the same base environment, the same solution structure, and the same configuration — no manual drift between engagements. The starter kit you build for the first client becomes the script you run for every client after.
• Scaffolding new projects. Teams that regularly spin up new apps or POCs stop treating environments as something scarce. A new feature branch can have its own throwaway environment for the duration of the PR. It is a script, not a request.

 
The bigger shift this creates is a mental one. Once you are using pac admin, you stop treating environments as fragile, permanent things you have to carefully manage. You start treating them more like containers — disposable, consistent, and easy to recreate when needed.  

3. Automating Deployments in Azure DevOps

Once your solutions are in source control as plain-text files and your environments can be provisioned from a script, the natural next step is automating your deployments entirely. This is where PAC CLI in an Azure DevOps pipeline brings everything together.  
 
You can set up a pipeline that packs your solution, authenticates to the target environment using a service principal, and imports it without any manual steps. Microsoft does ship a Power Platform Build Tools extension for Azure DevOps that wraps these commands as pipeline tasks, but you can also call PAC CLI directly in a pwsh step:

- pwsh: |
    pac auth create `
      --name prod `
      --tenant $(tenantId) `
      --applicationId $(appId) `
      --clientSecret $(clientSecret) `
      --url $(prodUrl)

    pac solution pack `
      --folder $(Build.SourcesDirectory)/src `
      --zipfile $(Build.ArtifactStagingDirectory)/solution.zip `
      --packagetype Managed

    pac solution import `
      --path $(Build.ArtifactStagingDirectory)/solution.zip `
      --async `
      --max-async-wait-time 60

With this in place, your deployments are repeatable, logged, and reversible.  
 
Even as a solo developer working on a single client engagement, a simple two-stage pipeline with a manual approval gate between dev and prod will eliminate most of the deployment errors that come from manually exporting and importing solution zips. Not to mention the time you save when working with large solutions that have tens or possibly hundreds of environment variables.  

Conclusion

In conclusion, the PAC CLI is one of those tools that quickly becomes something you wonder how you worked without. Start with pac solution unpack and get your solutions into source control this week. From there, add pac admin to start scripting your environment lifecycle. And when you are ready, build out a pipeline to automate your deployments end to end. Each of these on their own is valuable — together they significantly raise the quality and reliability of your Power Platform delivery.  

Keep an eye out for more articles coming soon, including a deeper look at setting up full ALM pipelines on Azure DevOps for Power Platform.