Every Power Apps engagement begins with the same pivot point. Canvas or model-driven? Newcomers default to Canvas - it looks more modern, the pixel-level control feels familiar from Figma and other design tools. Experienced teams default to model-driven - it scales, it gets ALM right out of the box, it is boring in a good way.
Neither default is correct universally. After building in both shapes for three years, here is the four-question framework we run before committing.
Question 1: does the core data model have more than ten tables with meaningful relationships?
Model-driven wins when the answer is yes. The framework generates forms, views, and relationships automatically. Adding a new column shows up on the form without manual rebuild. Views support complex filters, saved queries, and personal pins without a line of code.
Canvas wins when the answer is no. A Canvas app can be wired to two or three Dataverse tables cleanly. Past that, the formulas that bind controls to data get long enough that the maintenance cost exceeds the UI flexibility benefit.
The boundary is not exactly ten tables - it is "does the app feel like a CRM or a workflow tool?" CRM-shaped apps are model-driven natural. Workflow-shaped apps (inspection forms, approval requests, dashboards) are Canvas natural.
Question 2: does the UI need to be pixel-specific?
Canvas wins when the UI is the point. A customer-facing kiosk app, a mobile field-service tool with big buttons for gloved hands, a dashboard with a specific corporate brand treatment - Canvas lets you design the exact pixel layout.
Model-driven wins when UI consistency and auto-layout trumps design control. An internal CRM where users need forms to follow a predictable pattern across 40 record types should not have bespoke layouts per type.
The trap: a Canvas app designed for mobile portrait view breaks on desktop landscape. You either duplicate the screen for each form factor or build responsive layouts with App.Width conditional logic that is painful to maintain. Model-driven adapts to form factor for free.
Question 3: which devices need to run it?
Model-driven apps run well in:
- Desktop browsers
- Mobile via the Power Apps app (responsive-ish, some features degrade)
- Tablets via the Power Apps app
Canvas apps run well in:
- Mobile (native feel, offline support, camera/GPS/etc hardware access)
- Tablets
- Desktop via browser or Windows Player (functional but not as polished as model-driven desktop)
If your app is desktop-first for back-office users, model-driven is cleaner. If it is mobile-first for field workers, Canvas is cleaner. The middle case ("both desktop and mobile equally") is where people get stuck, and the tiebreaker is usually Question 2 - if UI specificity matters, Canvas; if not, model-driven.
Offline deserves a specific callout: Canvas apps have robust offline support via local collections and Dataverse mobile offline profiles. Model-driven apps have limited offline support via the Dataverse mobile offline sync, which is more restrictive. Offline-critical apps tend toward Canvas.
Question 4: who owns this app a year from now?
This is the question teams skip, and it is the one that usually decides.
Model-driven ages well because the framework is structured. A developer who has never seen your app can open a model-driven app, understand the data model from the entity list, find a form, and make a change without reading formula trees. Handoff is short.
Canvas apps age as well as the formula hygiene of the person who built them. A Canvas app with 40 screens, variables named var1 through var17, and 500-line OnSelect formulas on every button is unmaintainable. A Canvas app with disciplined naming, componentization, and consistent state management can be very maintainable - but it requires discipline the team may not have.
If the app will be handed over to client admins with no Power Apps background, model-driven is the safer bet. If it will be maintained by a developer team with Canvas experience and you have time to enforce code hygiene, Canvas can work. If it will be handed over and the client does not have developers, model-driven wins decisively.
The fifth question we do not ask explicitly
"Does someone on the team have strong feelings?" If a senior maker on the client side loves Canvas, fighting them into model-driven on a close call usually costs more than the gain. Conversely, a team that already has 20 model-driven apps and no Canvas experience should not build a Canvas app for a borderline use case.
Skill investment is real. Picking the framework your team maintains well is often the right answer even if the other framework would suit the problem slightly better.
How the four questions apply
Recent project: client asked for "a mobile-friendly app for their sales reps to log visits and orders on the road."
- Q1 (data model depth): 6 tables with relationships, customer / visit / visit-contact / order / order-line / product. Medium.
- Q2 (UI specificity): Reps want big buttons, step-by-step wizard, optional photo upload per visit. High specificity.
- Q3 (devices): Mobile-first, occasional tablet.
- Q4 (maintainer): Client's internal Power Apps team, two makers with Canvas background.
Three answers pointed Canvas, one was neutral. We built Canvas. Two years on, the app has evolved through three UI refreshes without touching the data model - exactly the pattern Canvas suits.
Hybrid is an option
The decision is not always one or the other. Some projects run model-driven for the back-office admin experience and a Canvas app for the mobile field experience, both hitting the same Dataverse tables.
The cost is maintaining two apps. The benefit is that each app is fit for its audience. We run this pattern on any project where the "office user" and "field user" personas need genuinely different interfaces on the same data.
If you are torn, write down your four answers and share them with the team. The decision usually becomes obvious once the questions are explicit rather than "Canvas feels right to me."
