Power Automate Versioning and Source Control - Export Tag Track

You changed a Power Automate flow last Tuesday. Something broke in production on Thursday. You want to compare what the flow looked like before and after your change. You open the flow designer and see… the current version. That’s it.

There is no “show me last Tuesday’s version.” There is no diff view. There is no blame history. Power Automate versioning and source control require you to get flow definitions out of the platform and into git. Solution versioning tracks the whole solution, not individual flows. If your solution has 30 flows and you changed one, the version history tells you the solution changed. Not which flow. Not what changed inside it.

This is the gap that kills teams at scale. You can’t govern what you can’t track.

How Do You Version Control Power Automate Flows?

You export flow definition JSON from Dataverse into a git repository, either through the native Dataverse Git integration or the pac CLI. From there, every change becomes a commit, every release gets a tag, and you can diff any two versions to see exactly what changed inside a flow.

The State of Flow Versioning in 2026

Power Automate gives you a few things out of the box:

• Run history. You can see past executions and their inputs/outputs. Useful for debugging, not for understanding what changed in the flow definition.
• Solution versioning. Solutions have version numbers (1.0.0.0, 1.1.0.0). But the version applies to the entire solution, not individual components.
• 28-day auto-save. Cloud flows keep versions for 28 days in the designer. You can restore a previous version. But you can’t compare two versions side by side. And after 28 days, they’re gone.

None of this is source control. Source control means: every change is recorded, every version is retrievable, and you can compare any two versions line by line.

To get real source control for flows, you need to get the flow definitions out of Dataverse and into git.

Two Paths to Git

There are two approaches. Microsoft’s built-in Dataverse Git integration (GA since April 2025) and the manual pac CLI workflow that teams have been using for years.

Both approaches end up in the same place: flow definitions as JSON files in a git repo, one file per flow, diffable and taggable.

Path 1: Dataverse Git Integration

Microsoft shipped Dataverse Git integration as GA in April 2025. It syncs solution components from a development environment to an Azure DevOps Git repo.

Here’s how it works:

The big advantage: makers can commit directly from the Power Platform maker portal. No CLI. No scripts. The big limitation: Azure DevOps only. If your team uses GitHub, you’ll need the pac CLI approach or a mirror setup.

Path 2: Manual pac CLI Workflow

The Power Platform CLI (pac) has been around longer and works with any git host. The workflow is more manual but gives you complete control.

The key commands:

# Export a solution as a ZIP file
pac solution export --name YourSolution --path ./exports/YourSolution.zip

# Unpack the ZIP into individual component files
pac solution unpack --zipfile ./exports/YourSolution.zip --folder ./src/YourSolution

# After making changes, re-pack for import
pac solution pack --folder ./src/YourSolution --zipfile ./exports/YourSolution.zip

# Generate deployment settings (connection references, env variables)
pac solution create-settings --solution-zip ./exports/YourSolution.zip --settings-file ./settings/dev-settings.json

When you unpack a solution, flows land in the Workflows/ folder as individual JSON files. Each flow has its own file named with its GUID and display name. The JSON contains the full flow definition - every action, every condition, every expression.

Your repo structure ends up looking like this:

your-solution-repo/
  src/
    YourSolution/
      Workflows/
        FlowA-{guid}.json
        FlowB-{guid}.json
        FlowC-{guid}.json
      Entities/
        ...
      PluginAssemblies/
        ...
      Other/
        Solution.xml
        Customizations.xml
  exports/
    YourSolution.zip
  settings/
    dev-settings.json
    test-settings.json
    prod-settings.json

The Git Workflow

Once your flow definitions are in git - whether through Dataverse Git integration or pac CLI - you treat them like any other code artifact.

Branching. One branch per feature or change. If you’re modifying the approval flow and the notification flow, that’s one branch with changes to two JSON files.

Commits. Meaningful commit messages that describe what changed in business terms. Not “updated flow” but “Added retry logic to vendor approval flow - 3 attempts with exponential backoff.”

Tags. Tag solution versions when you deploy. v1.0.0.0 matches solution version 1.0.0.0 in Dataverse. When something breaks in production, you can check out the exact version that’s running.

# Tag a release
git tag -a v1.2.0.0 -m "Release 1.2.0.0 - added vendor approval retry logic"

# List tags
git tag -l "v1.*"

# Check out a specific version
git checkout v1.1.0.0

Pull requests. Every flow change goes through a PR. The reviewer sees the JSON diff. They can see that you added a new action, changed a condition, or modified an expression. It’s not as readable as code, but it’s infinitely better than “trust me, I changed the flow.”

Diffing Flow Versions

Here’s where it gets interesting. Flow definitions are JSON. JSON diffs in git.

When you compare two commits, you see exactly what changed:

// Before
"actions": {
  "Send_approval": {
    "type": "OpenApiConnectionWebhook",
    "inputs": {
      "parameters": {
        "approvalType": "First to respond"
      }
    }
  }
}

// After
"actions": {
  "Send_approval": {
    "type": "OpenApiConnectionWebhook",
    "inputs": {
      "parameters": {
        "approvalType": "Everyone must approve"
      }
    }
  }
}

You can see that someone changed the approval from “First to respond” to “Everyone must approve.” In the designer, you’d have to open both versions (if you still have them) and click into each action to find the difference.

But raw JSON diffs of complex flows are hard to read. A flow with 40 actions produces a JSON file that’s thousands of lines long. Finding the meaningful change in a 200-line diff is tedious.

This is where AI helps. Copy the diff output and ask an AI to summarize it:

Here is a git diff of a Power Automate flow definition (JSON).
Summarize the changes in plain English:
- What actions were added, removed, or modified?
- What conditions changed?
- What expressions were updated?
- Are there any potential issues with the changes?

The AI reads the JSON diff and gives you something like: “The approval action was changed from single-approver to all-must-approve. A new parallel branch was added for a notification to the requester. The error handling scope was extended to cover the new branch.” That’s a code review you can actually work with.

Rewriting Flows with AI

This is experimental but powerful. Export a flow’s JSON definition, give it to an AI, and ask for specific improvements.

Things that work well:

• Add error handling. “Wrap each HTTP action in a try-catch scope with retry policy and failure notification.”
• Rename variables. “Change all variables from Hungarian notation (strApproverEmail) to descriptive names (approver_email_address).”
• Add comments. Flow JSON supports a description field on actions and scopes. Ask the AI to add descriptions explaining the business logic.
• Optimize expressions. “Simplify this nested if/coalesce chain into a cleaner expression.”

The workflow for AI-assisted flow rewriting:

1. Export and unpack the solution (pac CLI or git sync)
2. Copy the specific flow’s JSON file
3. Give it to the AI with specific instructions for what to improve
4. Review the output carefully. Check that connection references, trigger configuration, and environment-specific values weren’t changed
5. Replace the flow JSON in your unpacked solution
6. Pack the solution and import to dev
7. Test every path. Especially error paths.
8. Once validated, commit to git and promote through your pipeline

This is not a “let AI rewrite everything” approach. It’s targeted refactoring of specific flows where you know what you want to improve. The AI handles the tedious JSON manipulation. You handle the validation.

What This Looks Like in Practice

A government services team I worked with had 45 flows across 3 solutions. No version control. Changes went directly into the production environment. When something broke, the fix was “let me try to remember what I changed.”

We set up pac CLI exports on a weekly schedule. Every Monday, an Azure DevOps pipeline ran pac solution export and pac solution unpack for each solution, committed the results to git, and tagged the version. Total automation effort: one afternoon.

Within two weeks, the team caught a flow modification that removed an error handling scope. The weekly diff showed the scope was gone. Without git, nobody would have noticed until a failure hit production.

Within a month, the team started doing manual exports before and after each change. Not because someone mandated it. Because they could see the value of tracking what changed.

Getting Started

Don’t try to set up the full pipeline on day one. Start with this:

1. Install pac CLI: dotnet tool install --global Microsoft.PowerApps.CLI.Tool
2. Authenticate: pac auth create --url https://your-org.crm.dynamics.com
3. Export your most critical solution: pac solution export --name YourSolution --path ./YourSolution.zip
4. Unpack it: pac solution unpack --zipfile ./YourSolution.zip --folder ./YourSolution
5. Initialize a git repo: git init && git add . && git commit -m "Initial export of YourSolution v1.0.0.0"
6. Push to Azure DevOps or GitHub

You now have version control for your flows. Every export from this point forward is a new commit. Every commit is a diffable snapshot.

From there, add branching, PRs, tags, and automation as the team matures. The important thing is to start capturing the history.

---

Power Automate Governance - The Enterprise Playbook

This article is part of a 10-part series:

1. Naming Conventions That Scale
2. Environment Strategy - Dev Test Prod
3. Solution-Aware Flows
4. Flow Inventory
5. Pipelines - Dev to Prod
6. CoE Starter Kit
7. AI-Powered Flow Review
8. Versioning and Source Control
9. The Governance Repo
10. Weekly Governance Digest

---

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.