The 19 Laws of Power Platform Architecture
Howdang Rashid
Saturday, 22 August 2026 · 4 min read
Power Platform architecture has laws the same way physics does: you can ignore them, but they will not ignore you. These 19 - covering data, environments, ALM, governance, licensing, and the new world of agents - are the ones that decide whether a platform estate scales gracefully or collapses into an expensive rebuild.
Want the hi-res version? It's free in the Powercademy Success Kit.
What are the 19 laws?
Start with data - The Power Platform thrives on good data. Design the model before you touch apps, automations, or agents.
One source of truth - Pick where the real data lives (usually Dataverse). Don't duplicate unless you must; use virtual tables for integration where possible.
Tame the default environment - Use environment routing and guardrails so production apps are not running through the tenant's junk drawer.
Dev / Test / Prod (ALM) - Build an ALM process with Power Pipelines or Azure DevOps and keep a consistent deployment schedule.
Use solutions - If it's not in a solution, you can't package and deploy it, and structuring a process becomes much harder.
Low-code first - More code means more maintenance, which erodes the platform's whole benefit. Reach for code deliberately, not by default.
Use the right tool - Power Automate isn't for bulk data jobs. Sometimes the answer is Logic Apps, APIs, or SSIS.
Performance is a requirement - Delegation, views, indexes, pagination, and payload size aren't optimisations - they're requirements.
Governance stops disasters - DLP, policies, approvals, and managed environments don't slow teams down. They stop disasters.
Licensing up front - If your architecture needs premium connectors, say so early. Surprise bills kill projects; don't skimp to hide costs.
Reuse beats rebuild - Build shared components, shared connectors, and shared patterns.
Security-first design - Business units and roles define the real boundaries. Model them early, not after go-live.
Audit what matters - Dataverse auditing exists for compliance and tracking, and it consumes log storage. Be intentional.
Manage Dataverse storage - Keep capacity under control to avoid high costs and keep stakeholders happy.
Managed Environments to scale - Yes, they're expensive, but they add the control and insight admins need as adoption grows.
Error handling is not optional - Comment your code and manage errors in flows and apps. Untangling a huge uncommented flow is a developer's worst nightmare.
Treat agents as extensions of people - Register them in Agent 365, give them clear ownership, roles, permissions, and guardrails, and govern them properly.
Knowledge is a product - Garbage docs guarantee garbage answers. If your sources are messy, outdated, or contradictory, your agents will confidently deliver the wrong thing.
Best at scale - The Power Platform shines when everyone builds. Empower your users with guardrails to operate within; don't minimise them.
Which laws get broken most often?
Three show up in almost every troubled estate. Law 1, because teams design screens first and inherit a data model by accident. Law 10, because licensing surfaced at the end of a project instead of the start turns a technical win into a budget crisis. And law 3, because the default environment quietly accumulates production workloads nobody governs. The agent-era laws - 17 and 18 - are the newest and fastest-growing failure mode: agents deployed without ownership, grounded on documentation nobody curates.
FAQ
Do the laws apply to small solutions too?
The first five apply to everything - data first, one source of truth, solutions, and basic environment hygiene cost nothing at any scale. The heavier laws (Managed Environments, auditing strategy) earn their keep as adoption grows.
What does 'knowledge is a product' mean in practice?
Treat the documents your agents ground on the way you treat code: owned, versioned, reviewed, and retired when stale. An agent's answer quality is capped by its worst source, so curating knowledge is now an architectural responsibility, not an afterthought.
Is low-code first at odds with pro-code extension points?
No - it is a sequencing rule, not a ban. Exhaust the low-code option first, and when you do write code, keep it small, solution-aware, and justified by a limit you actually hit. The law targets code written by preference, not code written by necessity.
Who enforces these laws in an organisation?
Ideally a platform team or lead architect owns them, but enforcement works best as enablement: DLP policies, environment routing, and pipelines make the right path the easy path, so makers follow the laws without having to memorise them.
The hi-res version is in the Powercademy Success Kit - free, along with hundreds of other cheat sheets, roadmaps, and guides for Microsoft professionals.