Model-driven app

What is a model-driven app?

A model-driven app is a kind of Power Apps app built around a data model in Microsoft Dataverse. The maker picks tables, relationships, forms, views, charts, dashboards and navigation, and the platform turns those choices into a consistent user interface.

The word model-driven points at the data and process model. The interface follows the shape of the records and how they relate, so the maker does not draw every screen from a blank surface. Two model-driven apps built on similar data end up looking and behaving alike, which helps people move between them.

Model-driven apps use Dataverse as their data layer. External data can still appear in the model through integration or through virtual tables, but the app itself is grounded in Dataverse.

The building blocks

A table describes a business object, such as a customer, a case or an inspection. Columns hold its attributes and relationships connect records to one another.

A form shows or edits one record. A view gives a filtered list with chosen columns. Charts and dashboards summarise the data, and the sitemap and app pages set the navigation.

Business process flows can walk people through stages. Business rules, Power Automate and plug-ins add validation and automation, and security roles decide which tables and actions a person can reach.

A case-management example

A public service handles permit cases. A case links to applicants, documents, assessments, decisions and correspondence.

Staff open a view of their active cases, move into a record, and read the related documents and checks from there. A business process flow shows the stages intake, investigation, advice and decision, so everyone follows the same path.

This case suits a model-driven app because people look at a lot of related data and the process structure matters more than a fully free screen layout. A canvas app could show the same records, but rebuilding this navigation and these relationships by hand would be a waste of effort.

Design starts with the data model

Begin with the concepts, keys, relationships and ownership. A confused data model is not rescued by the generated interface; it just spreads the confusion across every form and view.

Split data into separate tables when it has its own life cycle or a many-sided relationship. Do not pile every field onto one large case form. Views, tabs and related tables keep the work readable. Reuse the standard tables Dataverse ships with when they fit, but watch for fields and behaviour they bring along that your case does not need.

Security

Dataverse applies security on the server. Security roles combine privileges such as read, create, write, delete, assign and share with an access level, so the model-driven app inherits that model rather than inventing its own.

Business units, teams, record ownership and sharing decide which concrete records a person can reach. Form logic that hides a field is a convenience, not data security, because another client can still read the value. Test roles with representative accounts, since an administrator sees more than an ordinary user and can miss an access problem that a normal account would hit.

Model-driven app versus canvas app

A model-driven app gives you a consistent, responsive interface for data-rich processes quickly. Forms, views and navigation behave in similar ways across apps, which shortens the learning curve.

A canvas app gives more freedom over placement, interaction and data sources. It often fits one focused task, a mobile checklist or a strongly visual experience better.

The choice is not absolute. A model-driven app can hold custom pages and code components, and an organisation can put a canvas app for field work and a model-driven app for back-office handling on the same Dataverse data.