Most Power Platform governance frameworks I see were designed for a tenant with twenty apps and fifty makers. Two years later the tenant has two hundred apps and five hundred makers — and the framework, if it still exists, is a set of documents that no longer reflects how things actually work.
Design for where you will be, not where you are
The governance framework you build today needs to scale without requiring a complete redesign when adoption grows. That means a few things:
- Automate enforcement where possible: governance rules enforced by tooling scale better than governance rules enforced by human review. DLP policies, environment provisioning controls, and automated compliance checks do not get more expensive as the tenant grows.
- Design the exception process as carefully as the rule: a governance framework without a clear exception process gets circumvented. People will find ways around rules that have no legitimate path to override them. Build the exception path deliberately.
- Tier your solutions by risk: not every solution needs the same governance treatment. A personal productivity app used by one person has different risk than a customer-facing portal used by thousands. Design a tiered framework that applies governance proportionate to risk.
The risk tiering model
A simple three-tier model works well for most organisations:
- Tier 1 — Personal productivity: apps and flows used by the maker and a small team. Low risk. Lightweight governance: naming convention, owner documented, reviewed annually.
- Tier 2 — Departmental: solutions used by a department. Moderate risk. Standard governance: solution structure, ALM pipeline, DLP reviewed, security roles documented.
- Tier 3 — Enterprise: solutions used across multiple departments or externally. High risk. Full governance: formal design review, security assessment, data classification, full ALM pipeline, ongoing monitoring.
Governance as service, not police
The governance frameworks that scale are the ones makers experience as helpful rather than obstructive. Governance-as-service: the CoE provides templates, tools, and advice that make it easier to build correctly than to build incorrectly. Makers are not policed into compliance — they are supported into it.
The governance framework that treats every maker as a compliance risk produces a culture of workarounds. The one that treats every maker as someone trying to do their job well produces a culture of collaboration.
Review your governance framework annually. As the tenant grows, the rules that made sense with twenty apps may not make sense with two hundred. Governance is not a one-time design — it is an ongoing practice that should evolve with your programme.
