Low-Code Is Not No-Governance
Power Platform needs the same architectural rigour as traditional development, just applied differently.
The promise of low-code was speed. Build an app in a day, automate a process in an afternoon, connect two systems without writing code. That promise is real, and Power Platform delivers on it. What the promise never included, though plenty of organisations heard it anyway, was that low-code means low-governance.
The governance requirements for a serious Power Platform deployment match those of traditional application development, with one extra complication: the tools make governance easy to bypass.
What ungoverned looks like
I’ve inherited ungoverned Power Platform environments more than once. The pattern repeats.
Hundreds of flows owned by people who left the organisation. A default environment holding thousands of apps, many connected to production data through connections nobody tracks. DLP policies configured once, written around whatever connectors existed at the time, blind to everything added since. No naming conventions, so no reliable way to search for anything. Managed and unmanaged solutions mixed in the same environment. Project environments never decommissioned after the projects ended, still running automations against live systems.
The people who built these things didn’t fail. The governance framework that should have existed before the first flow did. Power Platform is accessible enough to grow organically across an organisation before anyone establishes rules, and then the rules have to be retrofitted onto a system already in production. That’s the most expensive place to learn architecture.
Environment strategy is the foundation
Every serious deployment needs an environment strategy before anything gets built: a defined set of environments (development, test, production at minimum) with clear rules about what can exist in each and who can deploy to each.
The default environment is not a production environment. Not opinion; documented Microsoft position and practical reality. The default environment has no deployment pipeline, no isolation, no rollback capability, and every licensed user in the tenant can reach it. Running production workloads there is running production SQL Server on a developer’s laptop because it was convenient.
And an environment strategy without enforcement isn’t a strategy, it’s a document. Enforcement means Managed Environments, environment-level DLP, and deployment pipelines that promote solutions through a controlled process instead of manual export-import.
Solutions are not optional
Apps and flows built outside a solution can’t join a deployment pipeline. They have no controlled version history and can’t be rolled back cleanly. They just accumulate as technical debt wherever they were created.
Every production workload belongs in a managed solution with a custom publisher prefix. That’s not advanced practice; that’s the baseline. The prefix makes every component identifiable as belonging to its solution, which matters enormously once an environment has collected years of components from multiple teams.
Managed solutions add one more discipline: remove the solution and its components go with it. That’s the mechanism for clean decommissioning, and unmanaged solutions don’t have it. Over the lifetime of a production environment, the difference is not academic.
DLP policy is a security decision, not an IT checkbox
DLP policies in Power Platform control which connectors can be used together in a flow. They’re the primary mechanism preventing data from moving between systems in ways the organisation never sanctioned.
Most DLP policies I’ve reviewed were written without a clear picture of the data movement risks they were supposed to address. They block a list of connectors that seemed dangerous at the time and allow everything else. They haven’t been revisited since the connector catalogue expanded. They draw no line between connectors to consumer services and connectors to regulated internal systems.
DLP isn’t a one-time activity. Connectors get added to the catalogue regularly. Business requirements shift. A connector that was safe last year may be risky now because the data flowing through it changed. DLP is a living control, not a deployment artifact.
What governance enables
The standard argument against Power Platform governance is that it slows things down. Correct in the short term. Wrong over any horizon that matters.
Ungoverned environments slow down at scale. They fill with flows nobody understands and nobody dares touch. They fill with production-critical apps owned by no one. They generate audit findings that spawn emergency remediation projects. They make Copilot rollouts impossible, because the data governance those rollouts assume was never built.
Governed environments accumulate capability instead. Every solution is deployable. Every flow traces to an owner. Every environment is in a known state. Adding a workload means following a defined process, not tiptoeing through a maze of components that might break if touched.
Governance isn’t the alternative to moving fast. It’s what lets you still be moving fast after the ungoverned environments have hit their ceiling.