Episode Details

Have you ever rolled out a Power Platform solution, only to dread the manual deployment chaos that follows? It doesn’t have to be this way. Today, I’m walking through a step-by-step CI/CD setup using Azure DevOps so you can stop firefighting deployment issues and actually move your projects forward. Ever wondered which variables, connections, and pipeline steps actually matter? Stick around. You’ll finally see how to automate deployments without breaking a sweat.What Actually Goes Into a Power Platform Solution?If you’ve ever hit “export” on a Power Platform solution and then hesitated—wondering if you just forgot something critical—you’re not alone. It’s one of those moments where you expect to feel confident and organized, but then the doubts creep in. Did you pack up all those environment variables you painfully tracked down? Did that connection reference for your Flow actually make it into the file, or is it waiting to sabotage your next import? These aren’t academic fears. They’re the day-to-day reality for anyone who’s tried moving solutions between environments and found that “export” is only half the story. Even with Microsoft’s improvements, it’s rarely an all-in-one magic trick.Let’s talk about what actually ends up inside a Power Platform solution file—and, just as importantly, what doesn’t. Because this confusion isn’t just a minor detail; it’s often the very thing that will decide if your pipeline works or unravels in production. Teams get a false sense of security from that exported zip. On paper, it’s full of promise. But in practice, flows quietly break, apps throw strange errors, and half the configuration you expected to see just isn’t there.Here’s a classic scenario: a healthcare team spent weeks fine-tuning a patient intake app on their dev environment, built out with everything from Dataverse tables to Power Automate flows. They exported the solution, breathed a sigh of relief, and moved it straight into test. Suddenly, nothing connected. Flows wouldn’t trigger because connection references pointed to the wrong environment. Forms broke because environment variables for API URLs weren’t set. After hours lost retracing their steps, they realized those dependencies were never properly included or mapped. All the magic they built in dev just vaporized—because the export didn’t capture those moving parts.So, what exactly lives inside a Power Platform solution package? At the core, you’ve got Dataverse tables, which act like the backbone for all your business data. Then, you layer in Power Apps—both canvas and model-driven, depending on your architecture. These define the “face” of what your users actually interact with day-to-day. Next, flows: the automated Power Automate processes that glue together APIs, approvals, and custom logic in the background.This is where it gets tricky. Environment variables, for example, are designed for things like API endpoints, credentials, or toggles that differ between dev, test, and production. They don’t physically hold data—they’re like placeholders that expect to be filled in once the solution lands in a new environment. Similarly, connection references are just pointers to external services—Outlook, SharePoint, SQL, you name it. When you export a solution, these references come along as empty shells. On import, they need to be re-associated with valid accounts and credentials in that target environment. If you skip this part, or assume it’ll “just work,” you’re lining yourself up for those classic deployment headaches.This is why environment variables and connection references are not something you can set once and forget. They’re dynamic. Teams evolve, authentication schemes change, and what worked last sprint might dead-end next quarter. A Power Platform admin I know summed it up after a rough release window: “Every time we missed a variable, support tickets spiked.” Microsoft’s internal telemetry backs this up, showing that deployment failures due to misconfigured varia