Power Automate Dev Week Day 1: The Essential Toolchain (PAC CLI, VS Code, Solutions)

Quick Warm-Up  

Power Automate developers often start their first “real” project by opening the cloud designer, wiring a trigger to an action, and clicking Save —only to discover later that the artifact can’t easily be version-controlled, peer-reviewed, or packaged for other environments. Day 1 of Dev Week exists to prevent that pain. In this session we focus on the tooling trifecta— Power Platform CLI (PAC CLI), Visual Studio Code, and Solutions —that turns ad-hoc experimentation into repeatable, professional engineering.  

A tuned toolchain pays off immediately. PAC CLI lets you script every task you’d normally click through in the maker portal, so you can automate environment setup and enforce naming conventions from the moment your repo is cloned. Visual Studio Code, meanwhile, brings IntelliSense, linting, and Git integration to Flows, Dataverse tables, and custom connectors, so bugs surface in the editor instead of production. Solutions wrap the whole effort in a deployable package that your testers and admins will actually trust.  

Throughout today’s material we assume you have basic familiarity with Power Automate but have not yet installed any developer-first tooling. Each section builds on the previous one: we install PAC CLI, wire it into VS Code, then create and iterate on a Solution. By the end you will have a mini project you can push to DevOps—or delete and redo tomorrow, confident you can reproduce every step.  

Finally, a quick note about platform evolution. Microsoft ships monthly CLI updates and quarterly VS Code extension refreshes; commands or menus shown here reflect the July 2025 build. Where features differ across OSes (Windows-only pac data, for example) those caveats are called out inline.  

Why the Power Platform CLI Is Your Core Gear  

The Microsoft Power Platform CLI—invoked with the pac executable—encapsulates common admin, ALM, and maker-portal operations in a single cross-platform binary. Whether you need to list environments, initialize a Solution structure, or pull a Power Pages site for offline editing, the CLI offers a one-liner. Because it runs on Windows, macOS, and mainstream Linux distros, teams can standardize scripts without worrying about the developer’s laptop.  

Installation is frictionless when you use the Power Platform Tools extension for VS Code; the extension auto-installs the latest CLI and places it on your PATH. If you prefer standalone setups, Windows users can grab an MSI, while Linux and macOS folks can leverage npm or Homebrew. Keep in mind that a few packaging commands—pac package deploy, pac package show, and anything under pac data—remain Windows-only for now, so CI runners that call those tasks should use a Windows image.  

Authenticating is equally straightforward:  

pac auth create --kind ADMIN --url https://contoso.crm.dynamics.com        
	
	
	
	
	
	
	
	

stores a secure profile keyed to Entra Directory. You can maintain multiple profiles (DEV, TEST, PROD) and switch with pac auth select, ensuring your scripting targets the correct Dataverse instance. An immediate win on Day 1 is to script environment creation—  

pac admin create-environment --display-name "Dev Week Lab"        
	
	
	
	
	
	
	
	

so new team members can onboard in minutes.  

Finally, bookmark these three commands; you will run them constantly today:  

1. pac solution init --publisher-name ContosoDev --publisher-prefix cds – scaffolds a Solution folder.  
2. pac solution add-reference --path ./flows/MyFlow.flow.json – registers an existing Flow into the Solution.  
3. pac solution build --outputDirectory ./dist – zips a managed or unmanaged artifact for import.  

Master them now and the rest of the week feels trivial.  

2 – Tuning Visual Studio Code for Power Automate & Dataverse  

Visual Studio Code becomes the beating heart of your Day 1 workflow once the Power Platform Tools extension is installed. Besides shipping PAC CLI under the hood, the extension surfaces graphical explorers for environments, tables, and Solutions, letting you browse Dataverse entities in a tree view and double-click to open JSON or YAML definitions.  

First, curate your extension list. Power Platform Tools is mandatory; add Dataverse Schema Explorer for ERD-style navigation, YAML for syntax highlighting, and REST Client to craft authenticated calls against the Dataverse Web API. In settings.json enable "powerplatform.experimentalOutput": "verbose" so CLI logs are surfaced in VS Code’s Output pane, a lifesaver when pac solution build fails due to a missing dependency.  

Next, configure an integrated terminal profile that launches with the active PAC CLI auth context. Adding  

"terminal.integrated.env.windows": { "PAC_DEFAULT_PROFILE": "DEV" }        
	
	
	
	
	
	
	
	

ensures every new terminal points at the correct environment without an explicit pac auth select. Linux and macOS users can mirror the snippet under their respective OS keys.  

Finally, embrace VS Code’s debugging and linting. While Power Automate flows cannot be stepped through like C#, you can validate expressions and connectors offline. Use the extension’s Validate Flow command to catch typos in @{items('Apply_to_each')?['name']} before hitting Save . Pair that with Git hooks—husky plus pnpm works well—to block commits when validation fails. These small integrations turn VS Code into far more than a text editor; it becomes a quality gate.  

3 – Solutions 101: Packaging Work Like a Pro  

A Solution in Power Platform is a logical container for everything your app or integration touches—tables, flows, connectors, plugins, web resources, Power Pages, and even environment variables. The moment you move beyond a single developer sandbox, Solutions are non-negotiable because they provide the unit of transport for ALM pipelines. Microsoft’s documentation is blunt: unmanaged Solutions are for development, managed Solutions for everything else.  

Begin Day 1 by initializing a source-controlled Solution:  

pac solution init --publisher-name ContosoDev        
	
	
	
	
	
	
	
	

The command produces an src folder whose subdirectories (other, flows, tables, etc.) mirror the artifact types you’ll add. Resist the temptation to rearrange these folders; the CLI expects the default layout when it builds or imports. Place a solution.json at the root with semantic versioning—"version":"1.0.0.0"—so pipeline tasks can bump the build segment automatically.  

Managed versus unmanaged sparks endless debate, but the best practice is simple: develop and merge in unmanaged, export as managed in CI, and let higher environments import only managed artifacts. This pattern avoids solution-layering nightmares where Production ends up with a Franken-stack of unmanaged customizations. If your team needs hotfixes directly in Production, create a dedicated hotfix branch, export a patch Solution, and then merge back—never customize Production unmanaged.  

Versioning deserves explicit mention. Increment the build or revision number on every pull request; never overwrite an existing managed Solution version in environment history. Git-tagging the commit that produced ContosoDev_1_0_7_39_managed.zip makes rollbacks trivial because admins can select that exact build in the Power Platform admin center. Automation counts: add a pipeline task that reads the latest Git tag, bumps the revision, runs pac solution build, and publishes an artifact.  

4 – Putting It Together: A Walk-Through Mini Project  

Time to combine the tools into a hands-on scenario. Suppose you need a simple Flow that monitors a SharePoint “Proposals” library and posts to Teams when a file is approved. Begin with  

pac solution init --publisher-name ContosoDev --publisher-prefix cds        
	
	
	
	
	
	
	
	

in an empty repo. Next, in VS Code, open the command palette and run Power Platform: Create Flow ; choose the SharePoint trigger template. The extension generates FileApproved.flow.json under flows/.  

Add the Flow to your Solution metadata with  

pac solution add-reference --path ./flows/FileApproved.flow.json        
	
	
	
	
	
	
	
	

Notice that the CLI updates Solution.xml and customizations.xml automatically—no manual XRM calls required. Commit early: Git now tracks both the Flow definition and the Solution container.  

Ready to test?  

pac solution build --outputDirectory dist --buildConfiguration Debug pac solution import --path ./dist/ContosoDev_1_0_0_0_unmanaged.zip        
	
	
	
	
	
	
	
	

Within seconds the Flow appears in your DEV environment, complete with the original trigger and Teams action. Trigger an approval in SharePoint to validate end-to-end. If the Flow fails, switch back to VS Code, adjust the JSON (perhaps you mistyped the Teams channel ID), run Validate Flow , and repeat the build-import cycle. Each loop takes less than a minute.  

Finally, simulate promotion. Run  

pac solution export --type Managed --outputDirectory dist        
	
	
	
	
	
	
	
	

to create ContosoDev_1_0_0_0_managed.zip. Import this file into a TEST environment—either manually or via a pipeline stage that calls pac solution import. Because the Solution is managed, you’ll observe that the Flow is locked for editing. That’s intentional: testers and business users should exercise the artifact, not tinker with it. When issues arise, fix them in DEV, increment the revision to 1.0.0.1, and re-export. Within a single afternoon you have practiced true ALM.  

Best-Practice Checklist (Paste into Your README)  

• Install Once, Script Forever – Use the VS Code Power Platform Tools installer for PAC CLI; pin a minimum required version (e.g., >=1.34.0) in onboarding docs.  
• Authenticate Intelligently – Create separate pac auth profiles for DEV, TEST, and PROD. – Store tenant IDs and URLs in environment variables; never commit them.  
• Branch & Build Discipline – Adopt GitFlow-style feature , release , and hotfix branches. – Auto-bump the Solution’s build number during CI to guarantee uniqueness.  
• Managed for Every Non-Dev Environment – Export unmanaged → managed in the pipeline, not by hand. – Keep managed Solution history; avoid the “delete-and-import fresh” anti-pattern.  
• Guardrails in VS Code – Enable Validate Flow on save. – Run ESLint or a custom JSON schema to catch missing connectionReferences.  
• Secrets Stay Out of Source Control – Use environment variables or Azure Key Vault references in flow connections. – Audit commits for client IDs, passwords, or token strings before merging.  
• Document Everything – Update the README after each new PAC CLI command you adopt; future you (and your teammates) will thank you.  

With PAC CLI mastered, VS Code optimized, and Solutions flowing through your pipeline, you’ve laid the foundation for every subsequent Dev Week exercise. Keep the checklist handy, iterate with confidence, and enjoy a development experience that feels every bit as modern as the cloud services you’re automating.