Three Environments, Twelve Flows, and a Departing Employee
A shared-services team maintains a solution containing 12 cloud flows and 4 desktop flows, deployed to Dev, Test and Prod. Each cloud flow connects to SharePoint and Dataverse. Site URLs, library names and a vendor API base URL are typed directly into actions. Deployment is done by exporting the solution as a zip from Dev and importing it into the next environment, then opening every flow and re-pointing the connections by hand. Last quarter a production import succeeded but half the flows stopped running within a week; the connections had been created under an employee who then left the company. The team also cannot tell which flows changed between Test and Prod.
1. What should change in the solution's structure to remove the manual re-pointing during deployment?
Read the worked answer
Two solution components, used consistently:
- Environment variables for every environment-specific value: SharePoint site URL, library name, vendor API base URL, mailbox addresses. Values are set per environment, so the same solution artifact deploys unchanged and nobody edits actions post-import. Mark secrets as Key Vault-backed rather than storing them in the variable's text field.
- Connection references for every connector used by the flows. Each flow binds to a connection reference, not to a personal connection. At import time you supply the Dataverse and SharePoint connection references once for the whole solution, instead of editing 16 flows.
Additional structure: keep everything in a single publisher with a stable prefix, use managed solutions in Test and Prod and unmanaged only in Dev, and include the desktop flows in the same solution so their cloud-flow bindings travel with them. If any flow calls another, use a child flow inside the solution so the dependency is resolved at import rather than by name.
Reasoning: the goal is that deploying is configuration of references, not editing of logic. Any post-import edit to a flow is a divergence between environments that you can no longer diff.
2. How do you make the deployment repeatable and auditable, and prevent a leaver from breaking production?
Read the worked answer
Automate the promotion: use Power Platform Pipelines (or Azure DevOps with Power Platform Build Tools) so Dev → Test → Prod runs as a pipeline rather than a manual zip. Prerequisites: a host environment with Dataverse and the pipelines app, plus target environments registered. The pipeline should:
- Run Solution Checker before promotion and fail the run on new high-severity findings.
- Export managed, import managed, and set environment variables and connection references as pipeline parameters so the same inputs are reused each time.
- Keep a version number and a release note per deployment, which is how you answer 'what changed between Test and Prod'.
Ownership: flows and connection references must not be owned by an individual. Create an application user (service principal) in each environment and either own the flows with it or, where that is not practical, share the connections and reassign ownership as part of an offboarding checklist. A service principal credential is rotated on a known schedule and is not tied to employment.
Finally, add a post-deployment smoke test: a small flow that exercises each connection and writes a result to a Dataverse table, so a broken connection surfaces within minutes rather than a week later.