Power Platform governance: how mid-sized businesses succeed without losing control

What Power Platform governance actually is

Governance is not a switch you turn on. It is the set of rules that decide who can build what, where it gets built, which data it is allowed to touch, and who owns the result over time. Put plainly: guardrails, not a lockdown. The goal is that people can build safely, not that they cannot build.

The distinction matters because the wrong instinct is to react to a scare with a blanket ban: turn off connectors, lock the default environment, require approval for everything. That kills the very speed that made Power Platform worth adopting, and pushes building back into the shadows, into personal accounts and spreadsheets nobody can see at all. Good governance channels the energy; it does not switch it off.

Why it grows wild without structure

The sprawl is not a sign that people are doing something wrong. It is what happens when the barrier to building is low and no structure exists to catch the output. By default, everyone shares one open environment, connectors are wide open, and an app or flow is created in minutes to solve an immediate need. Multiply that across a few hundred employees over two years and the result is predictable.

Three failure modes recur. Orphaned ownership: the flow that runs payroll reminders belonged to someone who changed jobs, and now nobody knows how it works. Data exposure: an app quietly connects internal business data to an external service because no policy said it could not. And invisible dependence: a process the business now relies on turns out to rest on an app built as a quick fix, with no testing and no backup. This is the same risk the article on automating sales without building shadow IT describes. Here it is the whole platform, not one workflow.

A Center of Excellence, without enterprise bureaucracy

A Center of Excellence (CoE) sounds like a department. For a mid-sized organisation it should not be. It is a thin layer, often one person, sometimes a small group, that sets standards, offers templates and training, keeps an inventory of what exists, and steps in when something needs an owner. The job is to make the safe path the easy path, so makers follow it without being forced.

The visibility you need now sits in the Power Platform admin center: which apps, flows and agents exist, who made them, and how much they are used, so the conversation moves from guesswork to facts. Microsoft's CoE Starter Kit was the starting point for this for years, but it is no longer maintained and its capabilities have moved into the admin center. For most mid-sized organisations, visibility into the estate plus a couple of policies is already most of the value. The tooling is a means, not the goal.

The four moves that matter most

Most of the benefit comes from four decisions, in roughly this order:

• Environments. Stop building production apps in the default environment. A small set (development, test and production) gives work a place to live and a way to move forward safely, the same delivery-chain logic that matters at enterprise scale, sized down.
• DLP policies. Decide which connectors may be used together. Business data on one side, open external services on the other, kept apart so a well-meaning app cannot quietly bridge them.
• Ownership and lifecycle. Every app and flow that matters has a named owner and a plan for what happens when that person leaves. Solutions and source control keep changes from landing straight in production.
• Visibility. You cannot govern what you cannot see. A regular view of what exists, who owns it and what is unused turns governance from a one-off cleanup into something that stays under control.

Citizen developers: control that doesn't kill the value

The people building apps across the business (citizen developers) are the reason Power Platform pays off. Governance that treats them as a risk to be contained gets quietly ignored, or worse, drives them to build outside the platform where there is no visibility at all. The balance that works is enablement first: a safe environment to experiment in, templates that bake in the right choices, and a clear, fast route to get something promoted to production when it proves useful.

In practice this means separating the sandbox from the serious. Let people try things freely in a personal or team environment with limited data access; reserve the structure (review, ownership, monitoring) for the apps that have earned their way into production. Most of what gets built never needs to graduate, and that is fine. The governance effort should follow the value, not the volume.

Pattern: Across several projects we have seen organisations of 150 to 300 employees discover several hundred Power Automate flows and apps in the default environment, with only a smaller share still in active use. The fix was not a ban. It was a short amnesty to inventory everything, a handful of environments to move the keepers into, one DLP policy, and named owners for the dozen processes the business actually depended on. The volume fell, the useful work survived, and people kept building, now with somewhere safe to do it.

Why Copilot and agents raise the stakes

Governance used to be mostly about tidy apps. It is becoming about safe autonomy. Microsoft's 2026 Release Wave 1 makes agentic AI an organising principle: Copilot Studio agents that read from your data and act on your processes, orchestrated together. An agent given access that is too broad does more damage, faster, than a badly built app ever could, because it acts on its own.

So the fundamental governance work matters more than before. Environment structure, DLP policies, ownership and a clean data foundation are no longer just good practice. They are a precondition for adopting agents safely. We go deeper into the shift in agentic workflows in Dynamics 365 and into what Copilot does and does not do today in Copilot in Dynamics 365 Sales. The short version: the organisations with governance in place will be the ones who can safely say yes to agents.

When do you need this, and where to start

If a handful of people build a few apps on clean data, you do not need a governance programme, and we will say so. The case for structure grows when several of these are true: building has spread beyond a couple of people; apps and flows run things the business now depends on; nobody can list what exists; or you are about to add Copilot or agents. If that sounds familiar, the next step is small, not a reorganisation.

A sensible start is to get visibility first (inventory what exists and how much it is used), then put one DLP policy and a small set of environments in place, and assign owners to the processes that matter. That is a few weeks of work, not a year, and it gives a much better foundation for further growth.

How we do it in practice: we usually start by mapping environments, DLP policies, ownership and orphaned solutions. We then prioritise the measures by risk and business value, so that the most critical dependencies are handled first.

Much of this is supported directly in the platform. Managed Environments make it easier to enforce rules across environments, Power Platform Pipelines give a more controlled path from development to production, and Microsoft Purview can help with governance and compliance as the data estate grows more complex.

Across our Dynamics 365 and Power Platform implementations for Norwegian mid-sized organisations, the same challenges recur. That is why we build governance in from the start, rather than bolting it on as a cleanup project years later.

Conclusion

Power Platform governance is not about saying no. It is about making sure the yes you already said (let people build) keeps paying off instead of quietly turning into risk. For a mid-sized organisation, that means right-sized structure: a few environments, a couple of policies, clear ownership and honest visibility. Enough to steer, not so much that you stall.