Design Power Platform Architecture That Won’t Fall Over in 12 Months

Lessons learned from hard knocks, midnight flow failures, and too many environments named “Test2”

Let me tell you about the first Power Platform solution I ever inherited.

On the surface, it worked. People could click buttons. Data moved (mostly). Everyone seemed happy—until I opened the hood. It was like stepping into a house where every room had been renovated by a different builder… with no blueprint… and one of them had definitely used duct tape.

There were 12 environments (only 3 of them used), flows triggering other flows like some kind of automation inception, and security roles that made everyone an admin—except the actual admin.

That project taught me a lot about what not to do. And over time, working across sectors and organisations, I started spotting the same patterns again and again. So here’s what I’ve learned: if you don’t design your Power Platform architecture with a bit of structure and future-you in mind, it will start to fall apart. Maybe not today, maybe not tomorrow, but definitely around the time someone tries to scale it or take a holiday.

So if you're about to design a solution—or clean one up—here are the traps to dodge and the foundations to lay.

Environments: Pick a Lane

I once worked with a team where every new app had its own environment. By the end of year one, we had more environments than apps. No one could remember which was prod and which was “prod-but-not-really”.

Here’s what I now recommend:

• Set up Dev, Test/UAT, and Prod. Stick to them.

• Use Solutions religiously. Even for one-screen apps.

• Apply DLP policies so that someone can’t accidentally send sensitive data to their Gmail.

• Document who owns what. Otherwise, when something breaks, everyone’s a spectator.

The Data Model Is Not a Vibe

I’ve seen apps with 80 columns in one table, 25 of which were unused. And others using SharePoint to track case notes. For social workers. With client data. Yikes.

Here's what works:

• If data matters, Dataverse is your friend.

• Design for relationships, not just screens.

• Use flags, lookups, and choice columns deliberately—not just because they’re there.

• And always, always write down your schema decisions. Doesn’t have to be fancy. Just write.

Security: Because Everyone’s Not an Admin

One of my clients discovered six months in that every user had full delete permissions. Including interns. Thankfully, no one had noticed—or been curious.

Security’s not the sexy bit, but it’s essential:

• Design by role, not by person.

• Stick to least privilege access (a fancy way of saying “just enough to do your job”).

• Review permissions quarterly. You’d be surprised how things drift.

• And use Azure AD groups where you can. It’ll save your sanity.

Power Automate: A Blessing and a Curse

I love Power Automate. But it’s like caffeine: amazing in the right dose, chaos in excess.

If you don’t design your flows properly, you’ll end up with a tangle of dependencies where no one knows which one is doing what, or why.

Some sanity-saving habits:

• Map your processes first—whiteboard, Visio, napkin—anything.

• Break big flows into modular child flows.

• Set up failure alerts. Otherwise, your first sign of trouble will be an angry email.

• And don’t forget API limits. They sneak up on you.

Performance: Death by Delegation Warning

I once saw an app load a gallery with 25,000 records from SharePoint. Every. Single. Time. It technically worked. But not well. Or quickly. Or without tears.

Some friendly reminders:

• Watch your delegation limits in canvas apps.

• Use views and filters—load only what’s needed.

• Use Dataflows or Azure Data Factory when the data load gets heavy.

• Think about archiving before you need it.

Design Like It’s Going to Work (Because It Might)

Plenty of “quick wins” turn into business-critical apps. The trouble is, they weren’t built like it.

Treat MVPs like seedlings. Small now, but one day they’ll be trees.

• Set naming conventions and support structures early.

• Assign solution owners.

• Create a basic support process—even if it’s just a shared mailbox and a rota.

• If you’re in an enterprise: consider when to bring in Dynamics 365, Azure, or even a Centre of Excellence.

Document as You Go (Not Six Months Later)

Here’s the harsh truth: if you don’t document, your future self (or the next poor soul) will spend days trying to figure out why something was built that way.

Make documentation a living part of delivery:

A simple Confluence page or DevOps Wiki is fine.

• Include:

• System overview

• Environment structure

• Flow architecture

• Key decisions

• Known issues

Update it as part of your release checklist. No exceptions.

Build with Tomorrow in Mind

Power Platform is brilliant. Flexible, fast, and empowering. But if you build without structure, it’ll eventually trip over itself. And probably drag you down with it.

The good news? With a bit of forethought, a few guardrails, and a healthy respect for complexity, you can build lasting solutions. Ones that grow with your organisation—not against it.

So next time someone says “Can we just whip up a quick app?”, smile politely—and then architect like you mean it.

I'd love to hear some of your horror stories and strategies below...