When Power Platform is the right answer — and when it isn’t

It’s whether anyone made a deliberate call about which component fits which class of problem — and where the platform stops being the right answer at all. Five components matter. Each one solves a different problem.

Power Apps — canvas vs. model-driven

Two distinct products under one brand. They aren’t interchangeable.

Canvas apps

Pixel-positioned, drag-and-drop. The maker controls layout, navigation, and data sources. Canvas apps connect to many data backends — SharePoint, SQL, Dataverse, REST APIs — and are fundamentally about wiring a custom UI onto data.

Use canvas when the user count is bounded (low hundreds, sometimes low thousands), the data flow is mostly one record at a time, the screens are forms or dashboards, and the development time saved over a custom build is the point. Field inspection apps, mobile-first capture forms, replacing an Access database, replacing a spreadsheet macro — canvas earns its place in all of these.

Don’t use canvas when the app is read-heavy reporting (that’s Power BI’s job), needs sophisticated state or offline capability, or needs to conform to a wider corporate design system. Canvas apps that try to be enterprise UI almost always become a maintenance burden.

Model-driven apps

Generated from a data model in Dataverse. The UI is largely a consequence of the schema. Forms, views, business process flows, role-based security, audit trail, and offline-by-default are largely free — but the cost is conformance: the app looks like Dynamics, because that’s effectively what it is.

Use model-driven when the centre of gravity is a relational data model with multiple entities, role-based access, and a workflow story. Internal case management, asset registers, service request systems, regulatory tracking — model-driven sits very well here, and the built-in features that come with Dataverse are usually worth the per-user licensing.

Don’t use model-driven when the user need is a single workflow on a single entity, or when the business demands a bespoke UI that follows your corporate design language rather than the Dynamics chrome.

Power Automate — cloud flows vs. desktop flows

Cloud flows

Connector-based, server-side, triggered by events, schedules, or HTTP. The library of 1,000+ connectors is the genuine differentiator: SharePoint, Outlook, Teams, ServiceNow, SAP, Salesforce, Azure services, Atlassian, GitHub. If the integration question is “how do I move data from system A to system B when a record changes”, cloud flows are usually the cheapest defensible answer.

Use cloud flows for connector-based integration, approvals, scheduled exports, Teams-driven automations, and lightweight orchestration of three or four steps across systems.

Don’t use cloud flows as a replacement for a real integration platform when the orchestration is complex — long-running, stateful, branching with compensation logic. At that scale Logic Apps, or a proper iPaaS, earns its place. The flow editor stops scaling around 30–40 steps; past that you’re writing software in a graphical IDE that’s not designed for it.

Desktop flows (RPA)

Automate Windows applications by driving the UI. Best use is tactical: bridging a legacy system that doesn’t have an API while you build the replacement. Worst use is as the permanent integration strategy.

RPA bots are brittle to UI changes, expensive to license per attended or unattended bot, and a maintenance overhead that compounds. If you find a desktop flow has been in production unmodified for more than 18 months, you have either avoided a real integration project or quietly committed to one in technical-debt form.

Power Pages — external-facing low-code

The product formerly known as Portals. Power Pages is a low-code way to expose Dataverse data to authenticated or anonymous users outside the agency tenant. Purpose-built for citizen-facing forms, FAQ portals, partner extranets, and case-lookup pages.

Use Power Pages when the page is a form-and-data experience over Dataverse, the user volume is in the low tens of thousands, and the alternative is contracting a custom web build for what’s essentially a CRUD wrapper. The integration into Dataverse security is the value — you don’t reinvent authentication and authorisation.

Don’t use Power Pages for marketing sites, high-traffic content-heavy sites, or anywhere you need fine-grained design control. The customisation surface is real but bounded; if you’re fighting Liquid templates to achieve a layout, that’s a signal you’re using the wrong tool.

Copilot Studio — conversational AI

Copilot Studio (the rebrand of Power Virtual Agents, now with a generative-answer engine) builds conversational agents. Topic-and-intent flows for guided tasks; generative answers grounded against documents, SharePoint sites, or websites for FAQ-style work; a publishing channel into Teams, web chat, or Microsoft 365 Copilot.

Use Copilot Studio when the agent is doing FAQ retrieval over a known corpus, guided form-filling, or simple workflow triggering. It is genuinely good at standing up a useful internal bot in days rather than weeks.

Don’t use Copilot Studio when the agent needs sustained multi-turn reasoning, when the response quality requires custom model selection or a properly-engineered RAG architecture, or when answer governance has to be tighter than “publish-time grounding sources.” For those cases an Azure AI Foundry build with a chosen model and a deliberately-designed retrieval layer is the right tool — not a hosted no-code agent. Specifically: Copilot Studio’s generative answers are good enough for low-stakes information surfacing, and not good enough for advice that materially affects a person.

Dataverse — the platform underneath

Dataverse is the relational data layer that makes model-driven apps and Power Pages work. Tables with relationships, row-level security, business rules, an audit log, and a mature ALM story through solutions. It’s premium-licensed and capacity-metered.

Use Dataverse when the data model has more than two or three related entities, when row-level security matters, or when the platform’s built-in features (audit trail, business rules, role security) come for free in a way that would cost real money to build in a custom stack.

Don’t use Dataverse when the data is a single list — SharePoint lists, or a SQL-backed canvas app, are dramatically cheaper. Dataverse capacity (database, file, log) is metered and charged; an unplanned Dataverse footprint can be the line item that blows a programme budget in year two.

When Power Platform isn’t the answer at all

Five signals it’s the wrong tool:

• Transactional volume above roughly one million rows per day, or sub-second latency requirements. Dataverse and connector throttling are real ceilings.
• Rich domain logic with strong validation requirements that don’t fit cleanly into business rules and flow logic.
• Long-lived mission-critical systems where vendor commitment, exit cost, and licensing inflation matter materially over five-to-ten-year horizons.
• Multi-tenant SaaS-style isolation — Dataverse is per-environment, and the per-environment cost makes hard tenancy expensive.
• A team without Power Platform Centre-of-Excellence discipline. The technology is forgiving; the licensing and sprawl are not. Without environment strategy, ALM pipelines, and a CoE Starter Kit baseline, the platform’s productivity becomes its liability.

Licensing realities

Most adoption pain in NZ public-sector engagements is licensing pain in disguise. The headline points:

• Power Apps per-user vs. per-app. Per-user gives the maker freedom to build broadly. Per-app is cheaper for narrow use. Choose deliberately, and re-check the maths at user-count milestones.
• Premium connectors. Any non-M365 connector, in practice. Using one pulls the user into per-user licensing whether the project intended it or not. The connector reference in the documentation is the document to read before estimating.
• Dataverse capacity. Database, file, and log capacity are all metered. Plan capacity before, not after — particularly file capacity, which the platform makes it easy to forget about.
• Copilot Studio. Message-based, billed in conversation-message packs. Pricing tends to surprise programmes that scale a successful bot from a department pilot to an agency rollout.

The work isn’t to memorise the SKU sheet; it’s to know that licensing is a design constraint, not a procurement detail.

Governance: what actually matters from day one

The agencies that get value from Power Platform almost always do four things at the start:

• Environment strategy — default / dev / test / prod, with managed environments where appropriate, before the first app ships.
• CoE Starter Kit installed and consulted, even if not fully adopted. The visibility it gives over apps, flows, and makers is the difference between a controlled estate and one you’ll have to discover during an audit.
• A decision register for component choice — “we chose model-driven over canvas for X because…” — that lives with the platform and is consulted before each new app is started.
• An ALM pipeline — solution-aware, with managed solutions in non-development environments — from app one. Retrofitting ALM after an unmanaged estate has formed is materially harder than starting with it.

None of this is exotic. The reason it’s worth saying is that the productivity premise of Power Platform — anyone can build — leads agencies to skip these and discover their absence at the worst possible moment. Power Platform is one of the genuinely good productivity bets in the Microsoft ecosystem. It just stops being a good bet the moment you treat it as a no-decisions option.