Canvas app vs model-driven app
Verdict: Need full layout control or many data sources on one screen: canvas app. Need a data-dense process over related records with automatic responsive UI: model-driven app, which cannot be created without a Dataverse data model.
| Criterion | Canvas app | Model-driven app |
|---|---|---|
| Starts from | The user experience on a blank canvas | The shape of business data modelled in Dataverse |
| Layout | Maker controls every control, set via Power Fx | Largely determined by the components added |
| Data sources | Many sources at once through connectors | Dataverse only |
| Responsiveness | Only if the maker designs it that way | Automatic across devices, accessibility built in |
| Choose when | Pixel-perfect branded screen, or SQL plus SharePoint on one screen | Data-dense process moving between related records |
Rules
- Choose a canvas app when the maker needs full layout control and must bind to several sources such as SQL Server and SharePoint on one screen.
- Choose a model-driven app for data-dense process work where users move between related records; navigation through relationships is automatic.
- A model-driven app cannot be created without a data model housed in Dataverse; tables and relationships are its foundation.
- Model-driven apps are automatically responsive across devices with accessibility built in, delivered by the approach not the maker.
- Canvas apps start with the user experience and give full control of the layout through Power Fx expressions on control properties.
Traps
- Automatic responsiveness is a model-driven trait; canvas apps are responsive only if the maker builds it that way.
- Model-driven apps use Dataverse only; connecting directly to SharePoint, Excel or SQL Server describes a canvas app.
- Model-driven layout is set by the components added; free placement of every control on a blank surface is canvas only.