Canvas vs Model-Driven Apps: How to Actually Choose

Build model-driven when the app is about the data: many related tables, a process that moves records through stages, users who live in the app all day and need views, filters, search, and security roles more than they need a pretty screen. Build canvas when the app is about the task: one person, one job, one screen or two, often on a phone, often talking to something that is not Dataverse. When the same solution needs both, and it often does, the answer is not a coin flip. It is a model-driven app with custom pages, which is the option most decision guides leave out.

If you only remember one test: if you would describe the app by naming its tables, go model-driven. If you would describe it by naming the person and what they are doing with their thumbs, go canvas.

A canvas app is a blank surface. You place controls where you want them, wire them up with Power Fx, and connect them to whatever data source you like: Dataverse, SharePoint, SQL, Excel, a REST API through a custom connector, or several at once. Layout, navigation, validation, and error handling are yours to design, which means they are also yours to maintain. Microsoft's own summary of the design experience is "manipulation of control properties using Power Fx expressions," which is accurate and, depending on the day, either a promise or a warning.

A model-driven app starts from the data model instead of a blank page. You define tables, columns, and relationships in Dataverse, then assemble the app from components the platform already knows how to render: forms, views, charts, dashboards, business process flows. The interface is generated and automatically responsive. You get less say over how it looks and a great deal for free: search, sorting, filtering, record-level security, audit history, bulk edit, Excel export, and a navigation model that scales to dozens of tables without you drawing a single screen.

The two are not versions of each other. They are different products that share a licensing page and a maker portal.

Canvas apps get dismissed by people who only build back-office systems, so let's be fair to them: a large share of what organizations need day to day is exactly what a canvas app is for.

The task is narrow and the user is not a data person. A safety walk-through, an inventory count, a visitor sign-in, a quick approval on the go. The user opens the app, does one thing, closes it. Every extra menu, view, and ribbon button a model-driven app gives you for free is, here, something in the way.

The data is not in Dataverse. If the system of record is SQL Server, a SharePoint list, an ERP behind an API, or a spreadsheet nobody is allowed to retire yet, canvas is the app type that can talk to it directly. Model-driven apps are built on Dataverse; virtual tables can surface external data, but that is a projection into Dataverse, not a native connection, and it comes with its own limits.

The interface is the requirement. Branded kiosk screens, a guided wizard with three big buttons, a map, a barcode scanner, a signature capture, an app that has to match the look of something else the customer already uses. Model-driven apps can be themed; they cannot be redesigned.

It has to run on a phone, offline, in a glove. Canvas apps in Power Apps Mobile with offline profiles are built for that. A model-driven app on a phone works, and for a warehouse manager checking a queue it is fine, but it is a desktop information system rendered smaller, not a mobile app.

You need it this week. A competent maker can stand up a working canvas app for a bounded task in days. It will not be the app you keep for five years, and that can be entirely acceptable.

Canvas apps fail in a specific and predictable way: the task grows into a system, and the app was never a system.

The first sign is the second table. One table with a form and a gallery is a canvas app. Three related tables with lookups, a status that moves through stages, and two user roles who see different things is a small information system, and in canvas every one of those behaviors is code you wrote. Every new screen is a new place a bug can live.

The second sign is delegation. Canvas apps push filters and sorts down to the data source only when the connector and the function support it. When they do not, the app pulls a capped number of rows to the device and works on those, silently. The result is an app that returned the right answer in testing on two hundred records and the wrong answer in production on twenty thousand. Model-driven views query Dataverse server-side; delegation is simply not a concept you manage there.

The third sign is security. "Managers see everything, staff see their own" is a Dataverse security role and a couple of business units in a model-driven app. In canvas it is a set of If() expressions around visibility and a filter on every gallery, and one missed screen leaks data. Canvas apps can enforce Dataverse security too, if the data is in Dataverse, but the app cannot add security the data source does not have.

The fourth sign is the maintenance bill. A canvas app's layout, validation, and error handling are hand-built. Every platform change, every new column, every new role touches the app. The model-driven equivalent picks up a new column by adding it to a form.

Model-driven apps get talked down as "the boring option" and "just CRM." They are the boring option, and that is their whole argument.

The app is the system of record's front door. Case management, asset registers, request pipelines, vendor onboarding, anything where users will spend hours a week searching, filtering, and updating records. Model-driven gives every one of those users a consistent, accessible, keyboard-friendly interface with view switching, column sorting, quick find, and advanced filters, and you did not build any of it.

The process matters as much as the data. Business process flows put a stage bar across the top of a record and enforce what must be captured before it moves. Building that in canvas is possible; keeping it aligned with the model as it changes is where teams give up.

Security and audit are non-negotiable. Security roles, column-level security, hierarchy security, field auditing, and record sharing are platform features. For anything regulated, or anything an auditor will one day ask about, this is the difference between "it is configured" and "we believe the app enforces it."

The estate will outlive the person who built it. Model-driven apps are metadata. They travel in solutions cleanly, diff sensibly, and can be understood by the next admin from the table designer alone. A large canvas app is understood by reading Power Fx across two hundred controls.

Model-driven apps fail in a different way: the interface is the requirement, and the interface is not yours to change.

You cannot make a model-driven form look like anything other than a model-driven form. Themes adjust colors and a logo. If the customer wants a dashboard-first landing screen with three big tiles, or a step-by-step wizard for a rarely used task, the out-of-the-box app fights you.

Everything must be in Dataverse. That is a feature until the data you need is somewhere else. Virtual tables exist and are getting better, but treating them as a general-purpose "connect model-driven to anything" mechanism is how projects miss their dates.

It is premium licensing, full stop. Model-driven apps require Dataverse, and Dataverse requires a premium Power Apps license for every user. A canvas app on standard connectors runs under the Microsoft 365 license people already have. This is not a small difference for a two-hundred-person company deciding whether a request tracker is worth a per-user monthly charge. It is also not a reason to build a database on a list; it is a reason to make the licensing decision on purpose, early, with the numbers in front of you.

It is heavier than the task deserves for small things. A four-field intake form does not need a sitemap, a form designer, and a security model. Users notice when a tool feels like it was built for a bigger job than theirs.

Here is the part most comparison articles skip. Since custom pages arrived, the choice stopped being binary. A custom page is a canvas-authored page that lives inside a model-driven app: same navigation, same security, same solution, same Dataverse. You design it in the canvas designer with Power Fx and full layout control, then add it to the model-driven app's sitemap, open it from a command bar button, or show it as a dialog.

That changes the default answer for a lot of real solutions. The pattern we reach for most often:

The system is model-driven. Tables, relationships, views, forms, business process flows, security roles, audit. Users who work the queue all day get the generated interface, which is the best interface for that job.

The exceptions are custom pages. A branded landing page, a guided intake wizard, a visual planner, a mobile-shaped task screen for the one role that works on a phone. Each is a canvas surface where canvas is the right answer, without forking the app into two products with two security models.

Canvas components embedded on forms cover the small cases: a signature control, a map, a custom picker sitting on an otherwise standard form.

The trade-off is that custom pages inherit canvas's costs where you use them, delegation and hand-built layout included, and the whole thing is premium licensed because it is a model-driven app. If your data is not in Dataverse, this option is not available to you at all. But when the question is "we need a real system and two screens that do not look like one," this is the answer, and it is a much better answer than the fully canvas app you would otherwise talk yourself into.

There is now a pro-code door into the same platform. Power Apps code apps let a developer build a web app in a normal code-first stack (React, Vue, and others, in Visual Studio Code) and publish it into Power Platform, where it runs under the platform's identity, environment, and governance and can call Dataverse and the connector library directly from JavaScript. Microsoft's own framing is "full control over your UI and logic," which is the canvas promise without the canvas ceiling.

That makes code apps the answer to a question this post used to have to dodge: what do you do when the interface is the requirement and the data must stay on the platform and the team has real developers? Before, the choice was a canvas app pushed past what it was designed for, or a custom web app outside the platform with its own auth, hosting, and governance story. Now the web app can live inside the platform.

The trade-offs are real. Code apps are premium licensed for every user, same as model-driven. You are writing and maintaining code, with a build pipeline, dependencies, and a developer who has to still be around in three years; the whole point of canvas and model-driven for a small IT team is that you are not. And the feature set is younger than the other two: at the time of writing, Microsoft's documentation lists gaps around Power Platform Git integration, Power BI embedding, SharePoint forms, and the Windows desktop player, so check the current limits before you commit a project to it.

Where they belong in the framework: if your answers point to canvas because of the interface, but you keep hitting delegation, layout, or maintainability walls, and you have developers, a code app is the next step up rather than a bigger canvas app. If your answers point to model-driven, a code app is not a replacement for it; it is the same role a custom page plays, for a team that would rather write React than Power Fx.

Ask these in order. The first one that gives a clear answer usually decides it.

Who uses it, and for how long at a time? A person working records for hours wants model-driven. A person doing one task and leaving wants canvas. A mix wants model-driven with custom pages for the task roles.

Where does the data live, and can that change? Not in Dataverse and not moving: canvas. In Dataverse, or the project includes moving it there: model-driven is on the table. "We'll put it in Dataverse later" is a decision to build canvas now and rebuild later; say so out loud.

How many tables, and do they relate? One or two flat tables: canvas is fine. Three or more related tables with lookups and lifecycle: model-driven, or you will be writing a database engine in Power Fx.

Is there a process with stages and rules about moving between them? Yes: model-driven with a business process flow. Maybe later: still model-driven; adding a stage bar to a canvas app later is a rewrite.

What does security actually have to enforce? Row-level or column-level rules that differ by role: model-driven, or canvas strictly on Dataverse with the rules enforced in the security model rather than in the app. "Everyone can see everything": canvas is fine.

Is the interface the requirement? Branded, mobile-first, wizard, kiosk, or must match another product: canvas, or custom pages inside model-driven if the rest of the answers said model-driven.

Who pays, and for whom? Standard licensing only, and the users are not already premium: canvas on standard connectors, and accept the ceiling that comes with it. Premium is available or justified: the licensing stops being the deciding factor and the questions above decide.

Who maintains it in three years? A small team without a dedicated maker: prefer model-driven, where the platform does more of the work. A team with real Power Fx depth: canvas is a reasonable choice more often. A team with actual web developers and a demanding interface: consider a code app before stretching canvas.

You built canvas and it is time to move when: screens keep multiplying to cover roles and statuses; the delegation warning triangle has become furniture; security is a growing set of visibility expressions; the app has a "reports" screen that is really a view; or the person who built it left and nobody wants to open it.

You built model-driven and it is time to add custom pages (not to abandon the app) when: users skip the app for a specific task because it takes too many clicks; a role only ever touches one table on a phone; leadership wants a landing dashboard that the generated interface cannot provide; or you are considering a second canvas app "just for the field team" that would duplicate the security model.

For most organizations that already run Microsoft 365 and are building something that has to last, the default is model-driven for the system and custom pages for the exceptions, with canvas as a standalone choice when the task is narrow, the data is elsewhere, or the license line has to stay at zero, and code apps reserved for teams with developers and an interface that neither of the other two can deliver. The wrong answer is not canvas or model-driven. The wrong answer is choosing by what the maker already knows and calling it a decision.

If you are mid-decision, the Health & Governance Gauge looks at the estate you already have, including which apps are the wrong type for what they became, and gives you a defensible way to pick. If you would rather just describe the problem, do that.

Microsoft's own documentation for the platform facts above. Limits and licensing change; check them at decision time.

1. Overview of building a model-driven app with Power Apps: what model-driven apps are, and Microsoft's own comparison table against canvas apps.
2. What are canvas apps?: the canvas design model and its data-source flexibility.
3. Overview of custom pages for model-driven apps: converging canvas surfaces into a model-driven app.
4. Embed a canvas app on a model-driven form: the older embedding pattern and when it still applies.
5. Understand delegation in a canvas app: what canvas apps can and cannot push down to a data source.
6. Licensing overview for Microsoft Power Platform: where standard Microsoft 365 licensing stops and premium plans begin.
7. Power Apps code apps overview: what code apps are, the premium license requirement, and the current list of unsupported features.