A governance model that still works when you have 500 makers

A success problem

It usually starts well. A few enthusiastic people in finance automate an approval. Someone in operations builds an app that replaces a shared spreadsheet. Word spreads, licences are already there, and within a year hundreds of people are building.

Then the questions arrive. Why is there a flow sending customer data to a personal Dropbox? Who owns the app the warehouse depends on, now that its maker has left? Why does the default environment contain thousands of items nobody recognises?

The usual reaction is to lock things down. Requests need approval, connectors are blocked, new environments take weeks. Sprawl slows, but so does everything else, and the people who were creating the most value quietly go back to spreadsheets or find workarounds you can't see at all.

Good governance doesn't decide whether people can build. It decides how much support and control each thing needs once it matters.

Govern by zone, not by gate

Instead of one set of rules for everything, split your platform into three zones. Every app and flow starts in the zone with the fewest rules and moves up as it becomes more important. The rules follow the risk, not the technology.

The important part is the movement between zones. A personal flow that suddenly has forty users is a signal, not a violation. Your process should notice it, contact the maker and help them move it up a zone, with more support and more rules attached.

Five building blocks

1. An environment strategy people understand

Treat the default environment as a personal sandbox and nothing more. Give teams their own environments with a lightweight request process, ideally automated, and make sure critical solutions have separate development, test and production environments. If getting a team environment takes more than a couple of days, people will keep building in the default one.

2. Data policies that match the zones

Data loss prevention policies control which connectors can be used together. Keep the default environment tight: business connectors only, nothing that moves data to consumer services. Loosen policies per environment as the zone rises, and write down why each exception exists.

3. Visibility through managed environments and the CoE toolkit

You can't govern what you can't see. Managed Environments and Microsoft's Center of Excellence Starter Kit give you an inventory of apps, flows, makers and connectors, plus usage data. Start with the inventory and a handful of reports. You don't need every component on day one.

4. Ownership and lifecycle

Every app and flow beyond zone 1 needs an owner and a backup owner. Ask owners to confirm their solutions are still needed every six months, and archive what's inactive. When someone leaves the organisation, their solutions should be reassigned automatically rather than discovered after something breaks.

5. A community, not just a policy

Makers follow guidance they understand and ignore rules they don't. Run short onboarding for new makers, keep a library of approved patterns and templates, and appoint champions in each department who can answer questions before they become tickets. Celebrate good solutions publicly. It's the cheapest governance tool there is.

Measuring what matters

Counting apps and flows says very little about whether governance works. These numbers tell you much more:

• Share of active solutions with a named owner. The single best indicator of long-term health.
• Time to get a team environment. If it's growing, expect more building in the default environment.
• Solutions promoted between zones. Promotion means your process is spotting important work early.
• Orphaned or inactive items cleaned up per quarter. Sprawl is normal. Leaving it there isn't.
• Maker satisfaction. A short survey twice a year. If makers dislike the process, they'll avoid it.

Common mistakes

• Blocking first, explaining later. Sudden restrictions break things people rely on and destroy trust in the platform team.
• Treating every app like an enterprise system. A personal flow doesn't need a change board. Save the process for what matters.
• Installing the whole CoE toolkit at once. Start with the inventory, then add pieces as you need them.
• Making IT the only owner. Governance works best as a partnership between IT, security and the business, with clear roles for each.

Your first 30 days

You don't need a six-month programme to start. A practical first month looks like this:

1. Week 1: Take an inventory. Install the core CoE components or turn on Managed Environments and see what exists.
2. Week 2: Tighten the default environment's data policy and announce it clearly, with a route for exceptions.
3. Week 3: Define your three zones, set up an environment request process and identify the ten most-used solutions.
4. Week 4: Contact the owners of those ten solutions, agree which zone each belongs in and start your champions group.

After that, governance becomes a rhythm rather than a project: a monthly look at the numbers, a twice-yearly ownership check, and steady improvements to the maker experience.