Solution import / export pipelines for Dataverse

A Dataverse solution moves through environments — typically dev → test → prod, sometimes with additional pre-prod or staging layers — via export, import, and publish. Manual promotion is slow and error-prone. Pipelines automate this lifecycle, and there are now several distinct approaches with different trade-offs.

The lifecycle being automated.

1. Maker / developer builds in dev environment, creating components in an unmanaged solution.
2. Solution is exported as a managed solution package.
3. Package is imported to test environment.
4. Tests pass.
5. Package is imported to production.

Manual: download a ZIP, click upload in target environment. Repetitive, error-prone, no audit trail. Pipelines fix all three.

Approach 1: Power Platform CLI (pac). The command-line tool ships with everything needed for scripted solution management:

pac auth create --url https://dev.crm.dynamics.com
pac solution export --path mySolution.zip --name MySolution --managed
pac auth select --index 2  # switch to test environment
pac solution import --path mySolution.zip

Scriptable from any CI/CD runner — GitHub Actions, Azure DevOps Pipelines, Jenkins, GitLab CI. Minimal abstraction; pure commands.

Approach 2: Power Platform Build Tools. Microsoft-published tasks for Azure DevOps Pipelines and GitHub Actions:

• microsoft/powerplatform-actions/who-am-i@v1 — verify connectivity.
• microsoft/powerplatform-actions/export-solution@v1 — export.
• microsoft/powerplatform-actions/import-solution@v1 — import.
• microsoft/powerplatform-actions/pack-solution@v1 — pack unpacked solution.
• microsoft/powerplatform-actions/unpack-solution@v1 — unpack solution for source control.

These are wrappers over pac. Cleaner pipeline syntax; integrated with CI/CD tooling.

Approach 3: Power Platform Pipelines. A Power Platform–native, in-product capability under Managed Environments:

• Configure dev → test → prod stages in the maker portal.
• Makers click "Deploy" — solution promotes through the pipeline.
• Approvals at each stage.
• Audit log in the platform.

Designed for citizen developers; no need to learn YAML or CI/CD. Less powerful than full GitHub Actions; great for low-code teams.

Comparing the three.

| Aspect | pac scripts | Build Tools | Power Platform Pipelines | |---|---|---|---| | Audience | Pro devs | DevOps teams | Citizen makers | | Source control | Native | Native | Limited | | Approval gates | Via CI | Via CI | Built-in | | Branching strategy | Full | Full | None | | Solution patches | Yes | Yes | Limited | | Power Apps deployment | Yes | Yes | Yes | | Cost | Free | Free (license-dependent) | Bundled with ME |

Source control pattern. The mature pattern: solutions are not the source of truth. The source of truth is unpacked solution source in a git repository.

• pac solution unpack --zipfile solution.zip --folder src/Solution/ — explodes the ZIP into a directory tree of XML, JSON, JS, CS files.
• Developers commit changes to the source tree.
• CI pipeline packs the source back into a ZIP and imports to the environment.

This pattern enables diffs, code review, branching, conflict resolution — proper engineering workflow. The alternative (export-import shuttling) loses all this.

Managed vs unmanaged.

• Unmanaged — for development environments where active editing happens.
• Managed — for everywhere else; layers prevent unauthorised changes.

Promote unmanaged from dev → export as managed → import managed to downstream. Mixing layers creates messes.

Solution dependencies. A solution depends on tables, columns, web resources from other solutions. Pipeline must promote dependencies first. Most pipelines:

1. Build all solutions.
2. Topologically order by dependency.
3. Import in order.

Solution upgrades vs patches.

• Solution upgrade — replace the previous managed solution version completely; clean state.
• Solution patch — apply a delta on top of the previous version; smaller package.

For complex production deployments, upgrades; for hotfixes, patches.

Common pipeline failures.

• Missing dependencies — solution X imported before Y it depends on; fails.
• Schema breakage — column type change between versions; import fails.
• Workflow assemblies version mismatch — plug-in DLLs binary-incompatible with target.
• Solution layer drift — manual changes in target environment block the managed layer; "drift detection" should fail the pipeline early.
• Connection references missing — connections need to be created in target before solution imports.

Connection references and environment variables. Solutions reference external resources via:

• Connection references — abstract references to connectors; bound to actual connections per environment.
• Environment variables — configurable values per environment.

Pipelines set these up post-import — either through pipeline scripts or manual configuration. Without them, flows and connectors fail to run in the target environment.

Common pitfalls.

• No automation. Manual promotion in 2026 is hard to justify; pipelines pay back fast.
• Skipping test environment. "Just promote to prod" — production crashes; rollback under pressure.
• No rollback strategy. Bad import in prod; no clean way back. Always have export-of-previous before import-of-new.
• Secrets in pipeline scripts. Connection strings, API keys committed; rotate compromised credentials.
• No success metrics. Pipeline succeeds technically; nobody verifies the solution actually works in target.

Operational rule. Every production Dataverse environment should be downstream of a pipeline — not directly editable by makers in production. The pipeline enforces process, audit, and rollback safety. The maker's perception of "I just made a change" should be implemented as "the pipeline promoted my change," not as "I clicked Save in prod."