Why Manual Portal Deployments Are Costing You Weekends

By Mirko Peters · 2026-08-11

Picture this: It is Friday evening, just as you are planning to shut your laptop down for the weekend. Suddenly, a panicked message pings your phone. A critical pro…

Picture this: It is Friday evening, just as you are planning to shut your laptop down for the weekend. Suddenly, a panicked message pings your phone. A critical production fix was pushed through the Power Platform portal, and now half the workflows are broken, a vital plug-in registration is missing, and the user database is throwing silent errors. Instead of relaxing, you spend the next forty-eight hours manually hunting down missing dependencies and dragging and dropping zip files into a production environment. Sound familiar? If you rely solely on manual portal deployments, you are playing a dangerous game of deployment roulette.

In this article, we are going to dive deep into why abandoning manual UI deployments in favor of a scripted, code-first approach using the Power Platform CLI (PAC CLI) will save your weekends, ensure true governance, and bring predictability back to your release cycles. This written guide directly expands upon the concepts discussed in our related podcast episode, Build Reusable Components with Power Platform CLI. Be sure to give that episode a listen for an audio-first deep dive into these exact tooling strategies!

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

When you handle enterprise low-code and pro-code solutions, consistency is everything. Manual deployment processes are prone to human error, missed configurations, and a lack of auditability. Adopting the Power Platform Command Line Interface transforms how your team operates:

• Consistency: Script the exact same steps for DEV to QA to PROD, eliminating the "it worked on my machine" syndrome.
• Portability: Managed solutions with explicit references stop "missing component" surprises dead in their tracks.
• Traceability: Logs and explicit versioning make your entire deployment pipeline audit-ready.
• Speed with safety: Cut manual rework entirely while introducing automated rollbacks and validation gates.

Safe setup (without breaking what works)

Moving to a CLI-driven workflow doesn't mean you have to throw your current environment setup out the window. You can run it safely alongside your existing maker practices.

1. Install PAC CLI, ideally in an isolated environment like a sandbox VM or a dev container.
2. Create auth profiles per tenant and environment to ensure you never accidentally target the wrong database: 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 to verify your target before running any commands: pac org who pac solution list Verify you are in the right environment before touching anything.

Solution packaging workflow (core commands)

A predictable release pipeline relies on standardizing how solutions are built, packed, and pushed. Here are the core commands you need to master:

• Initialize solution repo: pac solution init --publisher-name Contoso --publisher-prefix cts
• Add references for your apps, flows, plugins, and web resources: pac solution add-reference --path ./src/plugins/Contoso.Plugins.csproj pac solution add-reference --path ./src/canvasApps/TimeOffApp.msapp
• Pack (build) your output files: pac solution pack --zipfile ./out/Contoso.TimeOff_1_2_0_managed.zip --processCanvasApps
• Export from DEV if you are pulling down maker changes: pac solution export --name Contoso_TimeOff --path ./out --managed true
• Import to QA/PROD securely: 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 for features, 1.2.1 for hotfixes). Tag your builds cleanly in git.

Plug-in DevOps (no more manual registration)

One of the biggest culprits behind broken weekend deployments is the dreaded manual plug-in registration tool. Forgetting to register a step or pointing to an old assembly version ruins production environments instantly.

• Build and register via CLI directly inside your automated pipelines: pac plugin init # once, to scaffold pac plugin push # registers/updates plugin assembly and steps from config
• Benefits include consistent execution steps across all environments, meaningful error logs, and easy rollbacks by simply re-pushing a prior build.

CI/CD skeleton (Azure DevOps/GitHub Actions)

To truly break free from manual deployments, you need an automated pipeline. Here is a standard stage structure for Azure DevOps or GitHub Actions:

Stages

1. Build: restore dependencies, compile plug-ins, and run pac solution pack.
2. Validate: execute pac solution check (Solution Checker), run unit tests, and lint your code.
3. Deploy to QA: run pac solution import, publish changes, and execute automated smoke tests.
4. Gate: enforce manual approvals and health checks.
5. Deploy to PROD: run the exact same scripted steps and tag the release in git.

Key variables

• ENV_URL, CLIENT_ID, TENANT_ID, and SECRET (or certificates) should be securely stored in Key Vault or Actions secrets.
• Connection references and environment variables should be populated post-import via automated scripts.

Environment variables & connection references

Hardcoding URLs or connection data inside solutions is a recipe for disaster. Instead:

• Keep environment variables and connection references outside the solution payload and set them per environment in the deployment pipeline:
  • Map connection references directly to production connectors.
  • Dynamically set API URLs, site IDs, team IDs, and feature flags.
• Automate this with PowerShell or PAC scripts right after solution import to prevent silent runtime failures.

Common pitfalls & fixes

• Wrong tenant/env → Always verify with pac org who and utilize named auth profiles.
• Missing dependencies → Use pac solution add-reference and pack; let the CLI fail early during the build phase rather than at production import.
• Unmanaged in PROD → Use managed solutions exclusively in upper environments; always test uninstalls and rollbacks.
• Manual plug-ins → Script your registrations; stop doing one-off portal uploads.
• Drift (DEV ≠ PROD) → Version every package strictly and forbid portal-only edits in higher environments.
• Secrets in YAML → Use Key Vault or Action Secrets, and favor certificates over client secrets where possible.

Quality gates (fast checks that save weekends)

• Solution Checker built directly into your CI pipeline via pac solution check.
• Smoke tests post-deploy: automatically trigger a key flow, create a test record, and verify that your plug-in fired successfully.
• Rollback plan: always keep the last known good managed zip file handy and automate re-import routines on failure.

Governance checklist

• 📦 Managed solutions only in QA and PROD environments
• 🔐 Key Vault/Secrets combined with cert-auth for service connections
• 🧭 Named auth profiles per environment; no "default" targeting
• 🧩 Connection references and environment variables scripted post-import
• 🧪 Solution Checker and smoke tests executed on every deployment
• 🗂️ Strict versioning, release tags, and changelogs per solution
• 📜 Deployment logs retained for compliance and auditing

Quick FAQ

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

Can makers use this without heavy DevOps?
Yes, makers can start with simple scripted exports and imports, gradually growing into full CI/CD pipelines over time.

What about Dataverse plug-ins?
Treat them like standard software code: build them, version them, and register them via PAC CLI as part of your core deployment pipeline.

By shifting away from manual portal clicks and embracing the power of the PAC CLI, you will not only bulletproof your release process, but you will also finally reclaim your weekends. To hear more about setting up these tools and optimizing your low-code architecture, make sure to listen to the full episode over at Build Reusable Components with Power Platform CLI!