Canvas apps vs model-driven apps: the shape of the build, decided before you commission it

Almost every version of this question asked out loud is really two questions tangled together: what shape of app should we build, and where should the records live. They are separable, and separating them is the whole trick. Where the records live is settled in Dataverse vs SharePoint lists for Power Apps — read that one for the data-layer argument, because nothing below re-opens it. This page is about the other half: the shape of the thing your users open, and what that shape commits you to for as long as you own it.

The two are coupled at exactly one point, and it is worth stating once so it stops being confusing. A model-driven app cannot exist without Dataverse. A canvas app can be built on Dataverse, or on a SharePoint list, or on anything else it can reach. So choosing model-driven settles the data layer for you; choosing canvas leaves it open. That is the entire dependency between the two decisions.

One decision does sit above both of these. If you have not yet settled whether to commission software at all rather than licence a packaged product, start with Power Apps versus buying off-the-shelf software. Every Microsoft behaviour described below was checked against Microsoft's published documentation on 17 September 2026, and each claim links to the page it came from.

What Microsoft actually means by each one

The definitions are less marketing-flavoured than most comparisons make them sound. Microsoft's guide to building canvas applications (opens in new tab) describes the canvas as “a blank design surface where you can drag and drop components to build exactly the user interface you need”, connected to data from hundreds of sources. You place every control. Nothing appears that you did not put there.

Microsoft's model-driven apps overview (opens in new tab) describes the opposite approach: a design that “focuses on adding components such as forms, views, charts, and dashboards to tables”, where “much of the user interface is determined for you”. The same page says it is often easier to think of them as data-model-driven apps, because without a data model housed within Dataverse you cannot create one at all.

Read those two side by side and the trade is obvious. Canvas buys you control and charges you for it in build effort and maintenance. Model-driven buys you a generated, consistent interface and charges you in layout freedom. Neither is the advanced option. They answer different requirements.

The question that settles it: one task, or the whole process

Here is the test we use in scoping, and it resolves most projects in a sentence. Is this a task somebody performs, or a process a record travels through?

A task is bounded. A technician files a daily log. A supervisor approves a purchase request. A driver photographs a delivery. One screen, one job, done in ninety seconds, usually on a phone, usually by someone who will not tolerate a second of friction. That is a canvas app, and it is what most small businesses picture when they ask for an app.

A process is a record with a life. A case is opened, qualified, assigned, escalated, resolved and reviewed; along the way somebody needs to see every related contact, note, task and attachment without leaving the record. Microsoft is explicit that model-driven apps are “especially well suited to process driven apps that are data dense and make it easy for users to move between related records”, naming onboarding, a sales process and member relationships as examples. If your requirement reads like that, a canvas app will reproduce it only by you hand-building every view, filter, form and cross-record link that a model-driven app generates from the data model.

When both sentences feel half-true, the honest answer is usually the hybrid further down this page rather than a compromise between the two.

The dimensions that decide it, side by side

The first five rows below are Microsoft's own comparison, restated; the last four are the ones that decide small-business projects and appear in no product documentation.

What the requirement sounds like in the room

Scoping calls settle faster when the requirement is said as a sentence rather than as a preference. These are the sentences we hear, and what each one implies about shape.

The licence consequence, in one paragraph

This is the part that changes the answer for a 20-to-200-person company, and it is not symmetric. A canvas app built on SharePoint, Outlook or Teams data runs on the seeded Power Apps rights inside the Microsoft 365 seats you already pay for. A model-driven app cannot: it is Dataverse-backed by definition, and Microsoft's Power Platform licensing FAQ (opens in new tab) states that accessing an environment with Dataverse requires all users to have a corresponding standalone Power Platform licence for each service being used. So the shape decision is also a recurring-cost decision for every person who opens the app, every month, forever. Work the actual numbers on Power Apps licensing for small business before you commit — the arithmetic changes with headcount, and it is the one part of this choice you cannot re-decide quietly later.

Two things this does not mean. It does not mean model-driven is the expensive option and canvas the cheap one — a canvas app on Dataverse, or on SQL through the gateway, carries exactly the same licence requirement. And it does not mean the licence should drive the design: a process that genuinely needs a modelled data layer will cost more in rework than it saves in seats if you force it onto a list.

Mobile is not the tiebreaker people expect

Both kinds of app run in the same Power Apps mobile app on iOS, Android and Windows, so “we need it on phones” does not decide anything by itself. What differs is the experience once it opens. Microsoft's own comparison marks model-driven apps as automatically responsive with a user interface that is similar across devices from desktop to mobile — which is a genuine strength and also the honest limitation. What you get on the phone is the desktop experience reflowed: the same site map, the same views, the same record-dense forms. It is excellent for a manager checking a case on the move and merely adequate for someone wearing gloves in the rain.

A canvas app has no such inheritance. If the job is three taps and a photograph, you can draw exactly that and nothing else. The trade is that responsiveness and accessibility are now your responsibility rather than the platform's, and both are routinely skipped by app builders who do not know to ask.

One operational detail that catches teams out: Microsoft's documentation for the Power Apps mobile app (opens in new tab) notes that a user needs a predefined security role in the environment before a model-driven app even appears in their list on the phone. The usual “it works for me but not for them” support call on a model-driven rollout is a security-role problem, not a mobile problem.

Who keeps it running after we leave

Ownership cost is the dimension buyers under-weight most, and it runs in the opposite direction to build cost. A model-driven app is configuration: adding a column to a form, adding a view, changing who may see which rows are all things a capable person on your side can be taught to do, and Microsoft ships them as solution components that move between development, test and production environments. A canvas app is a program. The logic lives in Power Fx spread across screens and controls, and the person who understands it is the person who wrote it. Microsoft's own comparison table concedes the point in its migration row, marking model-driven movement between environments as simple and canvas as potentially complex, since the data sources may need updating.

The practical consequence for a small business is about the third change request, not the first. A canvas app is faster to get live and slower to hand over. If nobody internally will ever edit the app and you would rather call us for changes, that asymmetry may not matter. If your plan is to own the thing, it matters a great deal, and it is worth pricing into the build. We work that trade through as part of what a Power Apps development project costs.

The hybrid nobody tells a small business about

The honest answer for a lot of projects is not one or the other. It is a model-driven core for the process, with canvas-style pages where the generated interface is wrong for the job — and Microsoft supports this directly rather than tolerating it as a workaround. Its documentation on the custom page (opens in new tab) describes it as a page type “which brings the power of canvas apps into model-driven apps”, usable as a full page, a dialog or a side pane, with connector data and Power Fx available inside it.

Three facts make this the pattern to reach for rather than an exotic option. Microsoft states that in most cases you should use custom pages instead of embedded canvas apps, for tighter integration and better performance. A custom page follows the licence of the model-driven app that hosts it and does not count toward app limits, because it is treated as a page rather than an app. And where the older embedded-canvas approach is used, Microsoft's licensing FAQ confirms that embedded canvas components within a model-driven app are recognised as a single app, so the pattern does not multiply per-app licences.

What it looks like in practice: the case, the job or the claim is a model-driven app your office team lives in, with views, relationships and security roles doing the work the platform is good at. The field intake — the bit that has to be simple enough for someone on a roof — is a custom page drawn like a canvas screen. One app, one licence position, two interaction styles, each used where it fits. There are limits worth knowing before you design around it: Microsoft advises not exceeding 25 custom pages in a model-driven app, and an existing standalone canvas app is not supported for reuse as a custom page — its screens must be migrated one at a time.

You chose wrong if…

Three symptoms come up often enough to name, and each is much cheaper to catch in week one than in year two.

Your canvas app has grown a navigation menu. When a canvas app acquires a record list, a detail screen, related-item screens and a menu to move between them, you have hand-built the thing a model-driven app generates for free — and you now maintain it. One or two screens is a canvas app. Twelve screens that navigate a record hierarchy is a model-driven app wearing a costume.

Your model-driven app is being fought rather than used. If most of the budget is going into making the generated interface look and behave like something else, the shape is wrong for the task, or the wrong part of the task is in the model-driven app. That is usually a custom page, not a rebuild.

Nobody can say which records people actually work with. If the requirement cannot be described as records and relationships, a model-driven app has nothing to generate from, and the project needs a data-design conversation before an app-shape conversation.

Where this sits in a fixed-fee build

On a scoped engagement the shape decision is made in the design conversation, in writing, before anyone opens a designer: the task or process test, the licence position for every person who will open the app, who will maintain it afterwards, and whether the hybrid is the right answer. That decision goes into the scope you approve before the fee is agreed, which is how our fixed-fee Power Apps consulting engagements work — senior US-based engineers, typically two to four weeks, 30 days of hypercare after go-live, everything built in your own tenant and yours to keep. See how the fixed-fee process works, or tell us what the app has to do and we will tell you which shape it needs before you commit to either.