Govern the platform before the apps

A low-code platform is an offer that’s hard to refuse: give every licensed user the power to build the app they’ve been begging IT for, and watch the backlog melt. For a mission-driven org with no architect on staff, that lands like rain after a drought. So someone clicks “enable,” and the building starts the same afternoon.

That is exactly the problem. Power Platform is not a tool you turn on and govern later. The moment it is live, makers are creating apps and flows against real data, and every governance decision you didn’t make in advance becomes a default you unwind by hand. Boring-first IT says the unglamorous part comes first: decide who builds, where, and what data may flow, before the first app exists. The guardrails are cheap on an empty tenant and expensive to retrofit onto a sprawling one. Here is that work, in priority order.

What ungoverned looks like (the sprawl)

The failure mode is not dramatic. Nothing explodes. It accumulates, quietly, as small conveniences that each made sense in isolation. Eighteen months after a governance-free launch, the picture is reliably the same:

• Hundreds of apps and flows nobody catalogued — built in the default environment by whoever needed them, owned by people who have since changed roles or left.
• Connectors reaching anywhere — a flow pushing records to a personal cloud account, another posting to an unvetted service, a generic HTTP action shipping data to an endpoint with no name on it.
• Load-bearing processes with no owner — built by one person, documented nowhere, one departure from silent failure.
• No audit trail — when something leaks, there is no inventory and no log to reconstruct it. The honest answer to “what do we have and where does its data go?” is “we don’t know.”

None of this is the makers’ fault — they used the platform exactly as designed. The gap is upstream: the guardrails that should have shaped where they built were never set. Below are those guardrails, in the order that gives the most protection per hour of effort.

1. Environments — decide where building happens

Every tenant ships with a default environment that every licensed user can build in, and it is the single biggest trap in the platform. It exists from day one, it can’t be deleted, and unless you intervene it is where all the sprawl lands. Treating the default environment as a real workspace is the original sin of Power Platform governance.

The boring-first move is to treat the default environment as untrusted — nothing important lives there — and give real work a governed home instead:

• Turn off self-service environment creation. By default, makers can spin up environments at will. Restrict creation to admins so the environment map stays one you can actually draw.
• Build a dev / test / production split. Real apps get developed in a dev environment, validated in test, and promoted to production with explicit maker and admin roles. Building something that matters should mean building it somewhere governed.
• Choose per-team vs. central deliberately. A small org can run a few central environments by function (one for finance apps, one for HR, a shared dev); a larger or more autonomous org gives each team its own environment set with a clear owner. Either works — what doesn’t is the unspoken default of “everything in the one environment Microsoft gave us.”

2. DLP — decide where data may flow

Environments decide where building happens. Data Loss Prevention (DLP) policies decide what it’s allowed to touch. This is the guardrail that stops a citizen-built flow from quietly shipping records out of the tenant, and the one auditors home in on. DLP sorts every connector into one of three classes, then forbids data from crossing between the first two inside a single app or flow:

• Business — connectors you trust with org data: those inside your Microsoft 365 and Dataverse boundary, plus vetted line-of-business services.
• Non-business — allowed but kept at arm’s length. A connector here cannot share data with a business connector in the same app, which kills most accidental exfiltration, because the dangerous combination is “read org data and send it somewhere personal” in one flow.
• Blocked — no business in your tenant at all. Generic HTTP, custom connectors, and consumer services belong here until there is a named reason and a named owner for each exception.

Write the DLP policy before makers arrive, scope it per environment (stricter on production, looser on a sandbox if you must), and treat exceptions as owned decisions, not the path of least resistance. The boundary you never drew is the one the leak walks through.

3. The CoE Starter Kit — see what you have

You cannot govern what you cannot see, and sprawl is invisible by default. Microsoft’s Center of Excellence (CoE) Starter Kit — itself a set of Power Platform solutions you install into a dedicated environment — is the free, supported way to make it visible, and it does the unglamorous inventory work for you:

• Full inventory — every app, flow, connector, environment, and maker, catalogued and kept current. The answer to “what do we have?” on a dashboard instead of a guess.
• Governance signals — orphaned apps whose owner has left, flows that haven’t run in months, connectors reaching outside the boundary, environments nobody remembers creating.
• Maker enablement, not just policing — welcome emails, training nudges, and approval flows that make governance a relationship with your makers rather than a crackdown.

Stand it up early, in its own environment, with a named owner. On an empty tenant it confirms your guardrails are holding; on a sprawling one it is the flashlight you use to find what you already lost track of.

4. ALM — build in solutions, not in the open

The last guardrail is how apps move through their life. The lazy path is to build directly in the default environment, edit live, and have no way to roll back — which is how a maker’s “quick fix” at 5pm becomes everyone’s outage at 9am. Application lifecycle management (ALM) is the boring discipline that prevents it.

• Build inside solutions. A solution is the unit you package, version, and move — exported from dev, imported to test, promoted to production as one reviewable artifact, not hand-copied screen by screen.
• Never edit production directly. Changes flow dev → test → production through managed solutions, so production is something you deploy to, not tinker with.
• Use environment variables and connection references so the same solution points at the right data in each environment, and a promotion is a deployment rather than a rebuild.

ALM is the difference between a citizen-built app that can be supported, handed over, and recovered, and one that exists only as a live thing in a single environment nobody dares touch.

If you’re already sprawled: retrofitting governance

Most orgs don’t read this before they switch the platform on. They read it after — three hundred apps deep, with a leak they can’t fully trace. The good news: the same four guardrails retrofit, just in a different order, without breaking the apps people depend on.

• See before you touch. Install the CoE Starter Kit first — you cannot remediate sprawl you can’t measure. The inventory tells you which apps are load-bearing, which are abandoned, and which connectors reach outside the tenant.
• Apply DLP in audit mode, then enforce. A hard policy dropped onto a live tenant breaks working flows and turns makers against you overnight. Start permissive, watch what it would block, give each affected flow an owner and a migration deadline, then tighten.
• Migrate the apps that matter out of the default. Don’t boil the ocean. Package the genuinely load-bearing apps into solutions, move them to a governed production environment with a named owner, and let the abandoned ones age out.
• Assign owners and decommission the rest. Every surviving app and flow gets a named owner who re-attests it; anything ownerless with no recent runs gets archived on a published schedule, not deleted in a panic.

Retrofitting is slower and more political than getting it right up front — the whole argument for boring-first. The org that set the guardrails on an empty tenant spent a half-day; the one retrofitting them onto a sprawl spends a quarter, much of it negotiating with the people whose tools it has to move. Same platform, same controls — the only variable is whether the dull decisions were made early or late.

When I built an internal-ops platform for a Vienna-based international organization, the governed-environment-and-inventory groundwork was never the part anyone wanted to talk about in the demo. It is the part that meant, two years on, we could answer “what do we run and where does its data go?” in an afternoon. The calm, governed, inventoried platform outlasts the loud, ungoverned one every time — and the boring move that makes it true is setting the guardrails before the first app, not after the first leak.