Build Reusable Components with Power Platform CLI

TL;DR

• Portal is great for building—not for repeatable deployment.

• PAC CLI gives you scripted packaging, dependency validation, and auditable deployments.

• Run side-by-side with the portal: safer auth profiles, managed solutions, automated plug-ins, CI/CD.

• Payoff: predictable releases, fewer hotfixes, faster recovery, real governance.

---

Why PAC CLI matters

• Consistency: Script the same steps for DEV → QA → PROD.

• Portability: Managed solutions with explicit references stop “missing component” surprises.

• Traceability: Logs + versions → audit-ready.

• Speed with safety: Cut manual rework; add rollbacks and validation gates.

---

Safe setup (without breaking what works)

1. Install PAC CLI (isolated if possible—use a sandbox VM or dev container).

2. Create auth profiles per tenant/env:

   pac auth create --name "Contoso-DEV" --url https://orgdev.crm.dynamics.com pac auth create --name "Contoso-QA" --url https://orgqa.crm.dynamics.com pac auth select --name "Contoso-DEV" pac auth list

3. Dry-run checks:

   pac org who pac solution list

   Verify you’re in the right environment before touching anything.

---

Solution packaging workflow (core commands)

• Initialize solution repo:

  pac solution init --publisher-name Contoso --publisher-prefix cts

• Add references (apps/flows/plugins/web resources):

  pac solution add-reference --path ./src/plugins/Contoso.Plugins.csproj pac solution add-reference --path ./src/canvasApps/TimeOffApp.msapp

• Pack (build):

  pac solution pack --zipfile ./out/Contoso.TimeOff_1_2_0_managed.zip --processCanvasApps

• Export from DEV (if needed):

  pac solution export --name Contoso_TimeOff --path ./out --managed true

• Import to QA/PROD:

  pac auth select --name "Contoso-QA" pac solution import --path ./out/Contoso.TimeOff_1_2_0_managed.zip --publish-changes true --activate-plugins true

Pro tip: Keep versioning tight (e.g., 1.2.0 feature, 1.2.1 hotfix). Tag builds in git.

---

Plug-in DevOps (no more manual registration)

• Build & register via CLI in pipelines:

  pac plugin init # once, scaffold pac plugin push # registers/updates plugin assembly + steps from config

• Benefits: consistent steps across environments, meaningful error logs, easy rollback (re-push prior build).

---

CI/CD skeleton (Azure DevOps/GitHub Actions)

Stages

1. Build: restore, compile plug-ins; pac solution pack.

2. Validate: pac solution check (Solution Checker), unit tests, lint.

3. Deploy to QA: pac solution import, publish; run smoke tests.

4. Gate: approvals & health checks.

5. Deploy to PROD: same scripted steps; tag release.

Key variables

• ENV_URL, CLIENT_ID, TENANT_ID, SECRET/cert (store in Key Vault/Actions secrets).

• Connection references & environment variables populated post-import via scripts.

---

Environment variables & connection references

• Keep them outside the solution payload and set them per environment in the pipeline:

  • Map connection refs → prod connectors.

  • Set API URLs, Site/Team IDs, feature flags.

• Automate with PowerShell/PAC scripts right after import to prevent silent runtime failures.

---

Common pitfalls & fixes

• Wrong tenant/env → Always pac org who + named auth profiles.

• Missing dependencies → Use pac solution add-reference + pack; let CLI fail early.

• Unmanaged in PROD → Use managed solutions only; test uninstall/rollback.

• Manual plug-ins → Script registrations; stop one-off portal uploads.

• Drift (DEV ≠ PROD) → Version every package; forbid portal-only edits in higher envs.

• Secrets in YAML → Use Key Vault/Secrets; prefer certificates over client secrets.

---

Quality gates (fast checks that save weekends)

• Solution Checker in CI (pac solution check).

• Smoke tests post-deploy: trigger a key flow, create a test record, verify plug-in fired.

• Rollback plan: keep last-good managed zip; automate re-import on failure.

---

Governance checklist

• 📦 Managed solutions only in QA/PROD

• 🔐 Key Vault/Secrets + cert-auth for service connections

• 🧭 Named auth profiles per env; no “default” targeting

• 🧩 Connection refs/env vars scripted post-import

• 🧪 Solution Checker + smoke tests on every deploy

• 🗂️ Versioning & release tags; changelog per solution

• 📜 Deployment logs retained (compliance/audit)

---

Quick FAQ

Do I have to abandon the portal?
No. Keep the portal for building; use PAC CLI for packaging, deployment, and governance.

Can makers use this without heavy DevOps?
Yes—start with scripted export/import and grow into full CI/CD over time.

What about Dataverse plug-ins?
Treat them like code: build, version, and register via PAC CLI as part of the same pipeline.