Canvas vs Model-Driven Apps: The Decision Nobody Explains Clearly
Every Power Apps project starts with this question. Here's a framework for making the right call — and the cases where the answer is both.
“Should we use canvas or model-driven?” is the question I get asked most often by teams starting a Power Apps project. Microsoft’s documentation explains what each one is. It’s less clear about when to use which.
Here’s the framework I use.
The One-Sentence Version
Use model-driven when your app is about managing structured data. Use canvas when your app is about a specific user experience or process.
That’s the rule. Everything else is detail.
What Model-Driven Does Well
Model-driven apps are generated from your Dataverse data model. You define tables, relationships, forms, and views — the app largely builds itself from that definition.
This means:
- Built-in list/detail/edit pattern. You get a working app very fast.
- Responsive by default. Works on mobile without extra effort.
- Accessibility. Microsoft maintains this for you.
- Business process flows. First-class support for guided, stage-based processes.
- Timeline and activity tracking. Notes, emails, tasks associated with records — built in.
- Advanced Find / views. Users can filter and sort their own way without you building it.
Model-driven apps shine when:
- Users spend most of their time creating, editing, and reviewing records
- You have multiple related tables that users navigate between
- You need audit history, business process flows, or dashboards
- Your audience is internal staff (not customers)
The tradeoff: you give up pixel-level control of the UI. Forms look like Dynamics 365. You can customize within the model-driven framework, but you’re always working within it.
What Canvas Does Well
Canvas apps are closer to traditional app development. You place controls on a screen, connect them to data sources, write formulas. The UI is entirely yours.
Canvas apps shine when:
- You need a highly custom UI or branded experience
- The workflow doesn’t map cleanly to a table’s CRUD operations
- You’re building a process flow with multiple steps that span different data sources
- Your users are external (customers, field workers) and need a clean, purpose-built interface
- You need offline capability (both now support it — canvas has had it longer and has broader offline support; model-driven mobile gained offline capability more recently for specific scenarios like Field Service)
- You’re embedding an app inside a Teams tab or SharePoint page
The tradeoff: you build everything. Delegation limits, gallery performance, patch() calls that need careful handling — it all requires more development effort per screen than model-driven.
The Decision Matrix
| Scenario | Use |
|---|---|
| Internal CRM / case management | Model-Driven |
| Data entry form for a specific process | Canvas |
| Field inspection app | Canvas |
| Approval workflow with complex UI | Canvas |
| Multi-table data management | Model-Driven |
| Customer-facing portal | Canvas |
| Sales pipeline management | Model-Driven |
| Multi-step guided process | Both (BPF in MD, or Canvas) |
| Offline support required | Canvas (broader support) or Model-Driven mobile |
| Dashboards and reporting | Model-Driven |
The “Both” Answer
For complex projects, the right answer is often: model-driven for data management, canvas embedded for specific high-complexity screens.
You can embed a canvas app inside a model-driven form. This is useful when a specific section of a form needs a UX that model-driven can’t provide — a drag-and-drop interface, a custom visualization, a multi-step wizard within a record.
The embedded canvas app has access to the model-driven context — it can read the current record’s ID and data — so you can build something purpose-fit without losing the surrounding model-driven structure.
The Third Option: Custom Pages
There’s a newer option that blurs the line: custom pages. A custom page is essentially a canvas app embedded natively inside a model-driven app’s navigation — not just as an embedded component in a form, but as a full page in the sitemap.
This gives you the best of both: the model-driven shell (navigation, sitemap, security, business process flows) with canvas-level UI freedom on specific pages. It’s ideal when 80% of your app fits the model-driven pattern but a few pages need custom UX.
Custom pages have access to the model-driven context and can navigate between themselves and standard model-driven pages. If the “both” answer from above appeals to you, custom pages are the cleanest way to implement it.
Common Mistakes
Building canvas when model-driven would have been faster. I’ve seen canvas apps that are essentially recreations of a model-driven app: list of records, click to open, form to edit. This took 3x longer than model-driven would have and the end result was worse (no Advanced Find, no timeline, manual pagination).
Building model-driven when the process doesn’t fit the record-centric model. Model-driven is “here’s a record, work on it.” If your app is “walk the user through 8 steps that touch 4 different systems,” model-driven will fight you at every turn.
Mixing data sources in canvas without understanding delegation. Canvas apps hitting Dataverse are fine. Canvas apps hitting SharePoint + Dataverse + SQL in the same app create delegation nightmares and unpredictable performance.
A Note on Performance
Model-driven apps load faster for large datasets because they’re server-side rendered. Canvas apps load their data client-side through Power Fx formulas. For a table with 10,000+ records, model-driven views and Advanced Find will outperform a canvas gallery on every metric.
If your canvas app starts needing Filter(), Search(), and CountRows() on large Dataverse tables, you’ve probably chosen the wrong app type for that use case.
The Licensing Angle
Worth mentioning: both app types are included in the same Power Apps per-user license. Model-driven apps require Dataverse (which has its own storage costs). Canvas apps can connect to non-Dataverse sources on a per-app license tier.
If you’re building for external users on a budget, canvas with a per-app license against SharePoint or SQL can be more cost-effective than model-driven with Dataverse.
If I’m being honest, I think canvas apps are overused. Teams pick canvas because the designer feels more familiar, then spend weeks rebuilding things that model-driven apps give you out of the box — views, filters, pagination, timeline, Advanced Find. For data-heavy CRUD operations, model-driven is almost always the right call.
Related articles
Cascading Dropdowns in Canvas Apps (Yes, It's Harder Than It Should Be)
A parent dropdown for Country, a child dropdown for City that only shows cities in the selected country. Here's the pattern, the delegation-safe version, and the reset behavior that catches everyone.
Lookup Columns in Power Apps: Create, Display, and Patch Without the Guesswork
Lookups are how Dataverse tables relate to each other, and they're the column type that causes the most confusion in Power Apps. Here's how to set them up and work with them in canvas apps.
Get the Current User in Power Apps
The User() function gets you started, but most real scenarios need more. Here's how to get the current user's details from Dataverse, including Business Unit, Team membership, and security role.