Model-driven apps in Power Apps are business applications where the screens are generated from a data model in Microsoft Dataverse rather than drawn by hand. You define tables, relationships, forms, views and security roles, and Power Apps builds a consistent, responsive app around them. They suit registers, case queues and inspection systems with many records and several roles. They are a poor fit for bespoke interfaces or public-facing sites.
Table of Contents
What is a model-driven app in Power Apps?
A model-driven app is a Power Apps application whose user interface is assembled from components you attach to Dataverse tables, such as forms, views, charts and dashboards, rather than designed screen by screen. Microsoft itself says it is often easier to think of them as data model driven apps, because without a Dataverse data model there is no app.
In a canvas app you place every control and write the logic that moves data between them. In a model-driven app you make decisions about data and process, and the platform makes decisions about layout. If you are still working out what Power Apps is and where it fits, start with our guide to what Power Apps can do for your business and come back here for this one app type. Once the data model exists the build is rapid and the app is accessible and responsive without extra work. Moving it between environments inside a solution is simpler too.
The table below lists the building blocks you configure in a typical model-driven app and what each one produces for the person using it.
| Component | What it controls | What users see |
|---|---|---|
| Dataverse tables and columns | Data structure, field types and validation | Records with consistent fields |
| Relationships and lookups | How tables connect | Related records and linked navigation |
| Forms | Data entry layout and behaviour | Create and edit screens for each record |
| Views | Lists, sorting and filtering | Grids, search results and work queues |
| Dashboards and charts | Summary and operational insight | At-a-glance panels |
| Security roles | Permissions and visibility | What each role can see and do |
| Site map | Menu structure | Predictable navigation across areas |
| Business rules | Field logic and validation | Fields shown, hidden or required automatically |
| Business process flows | Stage progression | A guided stage bar across the top of the record |
| Cloud flows | Automation around the record | Notifications, approvals and integrations |
Microsoft’s stated minimum is a licence, an environment with a Dataverse database, maker privileges in that environment, one table with one column, one view and one form. Past that minimum, add a table, a rule or a stage only when a step in the process needs it.
Model-driven app vs canvas app: which should you build?
Build a model-driven app when the work is a register or queue with a stable data model, many records and several roles. Build a canvas app when the interface is the product, the data lives outside Dataverse or the job is one task on a phone. The field systems we build usually end up as both.
What you are really choosing is who makes the design decisions, you or the platform. The comparison below is condensed from Microsoft’s own side-by-side table and from the points that change the outcome in practice.
| Question | Model-driven app | Canvas app |
|---|---|---|
| Where do the generated screens read from? | Dataverse only | Dataverse plus many other sources through connectors |
| Who controls the layout? | The platform, from your components | You, control by control |
| How consistent is the result? | High, every app looks and behaves alike | Low unless you enforce it |
| How fast to build once the data model exists? | Rapid | Proportional to the design |
| Responsive and accessible? | Automatically | Only if designed that way |
| Navigation between related records? | Automatic where relationships exist | Only where you write it |
| Moving between environments? | Simple, inside a solution | Can be complex if data sources change |
| Offline on a phone? | Offline-first by default in the Power Apps mobile app once enabled | Possible, but designed and tested by you |
The site inspections app we built for a NSW civil contractor is a typical example. The register, the roles, the filtered views and the inspection history sat in a model-driven app. The phone steps, scanning a QR code on site and capturing a signature and photos, ran in a companion canvas app that wrote to the same Dataverse tables.
Microsoft builds the same mix into the platform. Custom pages bring canvas app capability inside a model-driven app, and Microsoft recommends them over embedded canvas apps in most cases, for tighter integration. On a phone, though, a custom page could not scan a code or capture a photo as of September 2026. The limits section later in this post covers what to use instead.
Do model-driven apps require Dataverse?
Yes. A model-driven app cannot exist without a Dataverse database in its environment, because the app is generated from Dataverse tables, relationships and metadata. A SharePoint list or SQL table can be shown inside one through a virtual table, but the app still needs Dataverse, and virtual tables carry limits that rule them out for most registers.
The Dataverse requirement has a governance cost as well as the licensing one covered below. The Australian Signals Directorate’s Blueprint for Secure Cloud starts from a single Default environment with no Dataverse database. It says creation of new environments should be restricted to specific Power Platform service administrators. In an organisation that follows it, the first step of a model-driven build is a request to those administrators for an environment with a Dataverse database.
If what you already have is a SharePoint list, our guide to Dataverse tables covers when to migrate rather than connect. The short version for model-driven work: a virtual table has no offline caching, no business process flows, no auditing and no charts or dashboards. Only organisation-owned tables are supported, with no user-level security filtering. Put an inspections register on a virtual table and it loses its stage bar, its audit history and its offline mode.
What are the smarts behind a model-driven app?
Most of the work in a model-driven app happens in the logic around each record. Business rules set, hide or require fields. Business process flows carry a record through defined stages, and cloud flows run when Dataverse data changes. Between them they do much of what a training manual and a supervisor’s spot checks used to do.
Business rules apply logic to a table or a form without code. They can set, clear or default a column value, validate data and show an error message, and on model-driven forms a form-scoped rule can also set requirement levels and show, hide, enable or disable columns. Scope trips people up. A rule scoped to the table applies to model-driven forms and the server. A rule scoped to a form applies to that form only. So a rule that must hold when data arrives by import or integration is scoped to the table. Performance can degrade past 150 business rules on a single table.
Business process flows define stages and steps that render as a bar across the top of the form, which helps people enter data consistently and follow the same steps every time. You can require a step before the next stage opens, which Microsoft calls stage-gating. If any stage has required columns, the form cannot be saved and the record cannot move to a new stage until they are filled. You can run up to 10 active flows per table with up to 30 stages each and filter which flow a person sees by their security role. On an inspections register, a new inspector sees the stages in order and cannot save the form or move to the next stage while a required step is empty.
Cloud flows in Power Automate handle what happens around the record: notifications, approvals, follow-up tasks and integrations, triggered by Dataverse events rather than by a button on one screen. Our comparison of Power Apps and Power Automate covers where the line sits between an app and a flow.
How do security roles work in a model-driven app?
A user with no security role sees nothing in a model-driven app, so sharing the app means assigning one. Each Dataverse role grants privileges like create, read, write and delete on each table, and an access level decides how far each reaches: own records, own business unit, that unit plus its children or the whole organisation.
A first app often gives everyone organisation-level access, which should be restricted to match the organisation’s data security plan and reserved for managers with authority over the organisation. The table below maps the patterns we configure most to those access levels.
| Pattern | Access level in the role | Where it fits |
|---|---|---|
| Own records only | User | Individual task queues, personal follow-ups |
| Team or department records | Business unit or an owner team with user-level access where teams cut across the business unit tree | Service crews, site teams, regional offices |
| Managers see their area and everything below it | Parent: child business unit | Regional managers over several sites |
| See everything in the organisation | Organisation | Managers with authority over the whole organisation |
| Restricted subset | A separate table with its own role or column-level security | Incidents, complaints, HR matters |
Two practical rules follow from that. Decide record ownership before you build forms, because a table is owned either by users and teams or by the organisation, and that choice is hard to unwind later. And do not make everyone a system administrator “just for now”. A system administrator can see and do everything, so a privilege missing from the real roles stays invisible until go-live, when users first work under those roles. Nor does the shortcut save a licence. Every user needs a licence and a role to run a shared app anyway.
What does model-driven app licensing look like?
Every person who runs a model-driven app needs premium Power Apps use rights, because model-driven apps use Dataverse and are premium by default. Those rights come from a Power Apps licence, pay-as-you-go billing or a Dynamics 365 licence when the app runs inside the environment of the licensed Dynamics 365 application. Microsoft enforces this from February 2027.
Enforcement means a user without premium use rights cannot open the app. It ends a lenient period that covered model-driven apps, among other areas. The limited Dataverse rights included with some Microsoft 365 licences do not count. They do not entitle users to run standalone custom apps. Power Apps itself offers three ways to give a person premium use rights: Power Apps Premium per user for unlimited apps, Power Apps per app for one app in one environment and pay-as-you-go through an Azure subscription, where you pay only for the users who ran the app that month.
The per app option changed in 2026. Microsoft stopped selling the Power Apps per app SKU to new customers from 2 January 2026, announcing it in a licensing notice on 14 January 2026. Existing enterprise agreement customers can keep renewing and adjusting, and MPSA customers can use it until their agreement ends, then have 60 days to move. A clarification added on 6 March 2026 says existing and new CSP customers are not affected and that the SKU would be available to buy again from early April 2026. When Microsoft updated its licensing overview on 8 September 2026, it described availability for existing customers and CSP customers as varying. Australian SMEs typically buy through a CSP partner, so ask yours whether the per app plan is on offer before you design a build around it.
Two details decide how a hybrid build is licensed. Embedded canvas components inside a model-driven app count as a single app, and custom pages follow the model-driven app’s licence and do not count toward app limits. A separate canvas app is different. Under the per app plan and pay-as-you-go it is licensed on its own, while under Premium it is one of the unlimited apps each user already has. For a small field crew we usually recommend per app or pay-as-you-go, and Premium once each user needs more than a couple of apps. Keep per app and pay-as-you-go in separate environments, because per app licences cannot be used in a pay-as-you-go environment.
Model-driven app examples you can copy
The easiest check is to compare your process with patterns that already work. A model-driven app works when the data model is stable, the volume of records is high, the process repeats and different roles need different visibility. The four patterns below share those traits, and the table shows the tables and roles you would expect in each.
| Example app | Core tables | Roles | Why model-driven fits |
|---|---|---|---|
| Issue resolution and stage tracking | Issues, updates, categories, assignments, attachments | Reporter, coordinator, resolver, manager | High record volume, one process, strict visibility rules |
| Contractor compliance register | Contractors, licences, insurances, sites, renewal events, documents | Admin, site manager, compliance officer | Required fields, audit history, reporting and controlled access |
| Asset inspections and maintenance | Assets, inspections, defects, work orders, photos, locations | Inspector, scheduler, technician, supervisor | Repeatable forms, clear ownership, many related records over time |
| Site inspections with sign-off | Sites, inspections, checklist items, defects, signatures, photos | Inspector, site supervisor, compliance lead | Controlled register with required fields, scanning and sign-off in a canvas app alongside it |
The fourth row is modelled on the site inspections app we built for a NSW civil contractor. A canvas app or a model-driven app can produce an inspection form. The case for model-driven comes from the rules a register like that typically carries: a defect stays open until someone with the right role closes it, and each supervisor sees their own sites and nobody else’s. Rules like those live in the data model and the security model, and a model-driven app puts the build effort there instead of into screen design.
What model-driven apps cannot do out of the box
A model-driven app cannot give you a pixel-perfect layout or a public-facing site, and barcode scanning on a phone takes extra work. Its generated forms and views cannot read a data source outside Dataverse except through a virtual table. Microsoft documents an answer for each gap, and each is easier to scope in at the start than to retrofit later.
The table below covers the limits that come up most when we scope a build.
| You need | What stands in the way | The documented answer |
|---|---|---|
| Barcode or QR scanning on a phone | Microsoft’s embedded canvas app guidelines list barcode scanning as unsupported in embedded canvas apps, and in September 2026 custom pages on mobile were an online-only public preview without it | Form script calling Xrm.Device.getBarcodeValue or a code component using the component framework device API, both supported on the model-driven mobile client, or a separate canvas app using the barcode reader control |
| Bespoke layout or a guided task on the desktop | Layout is generated from components | A custom page, which Microsoft recommends over embedded canvas apps in most cases |
| External users or a public site | Model-driven apps are for licensed internal users | Power Pages, covered in our Power Pages vs Power Apps comparison |
| Data that stays in SharePoint or SQL | Generated forms and views read Dataverse only | A virtual table for the register within the limits Microsoft documents for virtual tables, or a custom page, which can use any Power Apps connector |
Signatures and photos are not in the table because a standard form can handle both. The pen input control captures a signature in a multiline text column on a standard form, in the browser and on mobile devices. In the Power Apps mobile app, inspectors can take pictures and attach them to timeline notes, offline as well, with one attachment per note.
The canvas layer has limits of its own. A form can have at most three enabled embedded canvas apps on the web client, and publishing the form does not publish the embedded app. Custom pages remove most of those limits on the desktop, but Microsoft listed custom pages on mobile as a public preview in September 2026, online only, with no barcode scanning, photo capture or attachments. An app should have no more than 25 custom pages. On a field app, decide early where scanning will run. A separate canvas app can change the licence count, as the licensing section explains.
How do you build a model-driven app without rework?
Start with a solution and leave the screens until last. In between, settle the data model, then the security model, then the process. In our experience, the projects that run long did it in reverse, starting with forms and discovering at user testing that nobody had agreed who owns a record or which fields are required.
- Create a solution first and build everything inside it, so the app can move through development, test and production environments.
- Agree the primary record (site, asset, case, request) and what hangs off it (people, documents, activities, locations). Decide one-to-many versus many-to-many now.
- Decide ownership and access level per table before you touch a form. Apply column-level security to the sensitive fields, noting that it is not supported in mobile offline mode.
- Define the process as stages and required steps, on paper first. If it needs more than five tables or 30 stages, it is two processes.
- Configure business rules and flows against the data model, not the screen. Use table-scoped rules where the logic must hold on import.
- Build forms, views and the site map last and keep them lean. For mobile users, add only the tables and views field staff need. Dedicated mobile forms are one way to keep forms lightweight.
- Add a custom page for a desktop task, or a code component or companion canvas app for a phone task, only where step six could not do the job. Scanning and a guided single task are the usual cases.
The Australian Bureau of Statistics reported in June 2026 that 10% of businesses actively collected or analysed data to make informed decisions in 2024-25, down from 24% in 2021-22. Steps two to four are where a register starts producing that kind of data. Once every record carries a site, a status and an owner, a dashboard can show how many defects are open at each site and who owns them.
Common mistakes that slow model-driven projects down
The mistakes that stretch a model-driven project are mostly decisions left unmade: building screens before the data model is agreed, leaving security roles to the end, having no environment pathway, adding tables too early and over-customising an interface the platform would have generated for free.
Microsoft’s 2026 Work Trend Index, published in May 2026, surveyed 20,000 knowledge workers who use AI at work across ten markets including Australia. Of those, 45% said it feels safer to focus on current goals than to redesign work with AI. We see the same instinct in app projects, as a request to rebuild the paper form exactly as it was. A paper form has nowhere to put a stage, an owner or a required field. Redesign the process first, then let the platform generate the form.
Most of these mistakes have the same fix: work through the data model and the security model in a workshop with the people who own the process, before anyone opens the app designer. It adds about a week at the start and saves you unpicking roles and relationships after go-live.
Frequently asked questions
What is a model-driven app in simple terms?
A model-driven app is a Power Apps application where you define the data (tables and relationships), the process (stages and rules) and the roles, and Power Apps generates the screens. It suits work where many people handle many records under different permissions, such as a register or an inspection system.
Are model-driven apps the same as Dynamics 365?
No, but they share a platform. Dynamics 365 Sales, Customer Service and Field Service are model-driven apps Microsoft built on Dataverse, which is why a custom model-driven app looks and behaves like them. A custom app does not need a Dynamics 365 licence unless it uses Dynamics 365 restricted tables.
Can a model-driven app use a SharePoint list or document library?
Not as its native data source. A SharePoint list can be shown through a virtual table, but Microsoft’s documented limits for virtual tables include no offline caching, no business process flows, no auditing and no user-level security filtering. For documents, the common pattern is Dataverse records with SharePoint document management enabled, so files live in SharePoint and the record lives in Dataverse.
Do users need a licence to run a model-driven app?
Yes. Model-driven apps are premium by default, so every user who runs one needs premium Power Apps use rights, through Power Apps Premium, a per app plan where available, pay-as-you-go or a Dynamics 365 licence where the app runs in the same environment as the licensed Dynamics 365 application. The limited Dataverse rights that come with some Microsoft 365 licences do not cover standalone custom apps. Microsoft enforces the requirement from February 2027.
Can model-driven apps work offline?
Yes. Once a maker enables offline and defines an offline profile, the Power Apps mobile app runs the model-driven app offline-first by default, storing the profile’s data on the device and syncing changes when a connection returns. Business process flows work offline when the flow spans a single table.
Are Power Apps being deprecated?
No. Microsoft’s 2026 release wave 1 made the modern look the required experience for model-driven apps in its April 2026 rollout, with no switch back to the classic look. Licensing changed in 2026 too. From 2 January 2026 Microsoft stopped selling the per app plan to new customers through some purchasing channels, and it enforces premium licensing for model-driven apps from February 2027.
Confirm the fit before you build
If your process is a register, queue or inspection cycle with a stable data model and several roles, a model-driven app is usually the right core, with a canvas app or custom page for what a standard form cannot do. To check yours, book a free initial conversation with our Power Apps team and bring the paper form and spreadsheet.
