A practical guide to model-driven apps

Model-driven apps are the fastest way to turn a well-structured data model into a working business application. Instead of laying out every screen by hand, you describe your data in Dataverse — tables, columns, relationships and choices — and the platform generates a consistent, responsive, accessible application around it. Forms, views, dashboards and navigation all derive from that model, which is exactly why the approach is called model-driven.

For teams that live in Dynamics 365 or the wider Power Platform, this is a natural fit. The application inherits the platform’s security model, auditing and integration surface for free, and you spend your effort on the things that are genuinely specific to your business rather than rebuilding plumbing that already exists.

When a model-driven app is the right choice

Model-driven apps shine when the application is essentially a rich, governed interface over structured relational data. If your users create, read, update and relate records — customers, cases, orders, assets — and you need role-based security, auditing and a consistent experience across desktop and mobile, this is the tool.

They are less suited to highly bespoke, pixel-perfect layouts or task-first mobile experiences; that’s where a canvas app fits better. A common and effective pattern is to use both: a model-driven app for the back office where data density and process matter, and a focused canvas app for a specific field task, both sharing the same Dataverse tables underneath.

Start with the data model

Everything good about a model-driven app flows from a clean Dataverse schema. Before building screens, get the tables and relationships right:

• What are the core entities, and how do they relate?
• Which columns are genuinely required, and what are their correct data types?
• Which values should be constrained to a fixed set of choices rather than free text?
• Do any records need an alternate key so integrations can reliably match and upsert them without creating duplicates?

A little discipline here — sensible naming, the right data types, thoughtful relationships — pays off across every form, view and report you build later. It is far cheaper to get the model right at the start than to restructure it once data and customizations depend on it.

Forms: focus over density

Forms are where users read and edit records, and the temptation is always to put everything on one screen. Resist it. Group related fields into sections, use tabs to separate concerns, and hide what isn’t relevant to the task at hand. A form that shows the ten fields someone needs is far more usable than one that shows all sixty.

Business rules let you add logic without code: showing or hiding fields, setting values, making fields required or read-only based on other values. Because they run consistently on the client and server, they are the right place for simple, declarative behaviour that should always hold. When the logic grows beyond what a business rule can express cleanly, that’s the signal to move it into a plugin.

Views: the lists people actually work from

Views define the lists users work from every day, and a good set of views does more for productivity than almost anything else. Design them around real tasks: “my open cases”, “orders awaiting approval”, “assets due for service”. Filter and sort them so the first thing a user sees is the thing they need to act on.

When a grid genuinely can’t express what users need — a scheduling board, an inline editor, a rich visualisation — that’s the moment to reach for a PCF control rather than compromise the experience. But most of the time, the right views get you most of the way there with no custom code at all.

Security that mirrors the business

Dataverse security roles let you model who can see and do what, down to the table, record and even column level. The key is to design roles around real job functions rather than bolting on permissions ad hoc.

When roles reflect how the organisation actually works — “dispatcher”, “field engineer”, “finance approver” — the system stays understandable as it grows, and you avoid the classic trap where everyone quietly ends up as a system administrator because it was easier than getting the roles right. Business units and teams then let you scope access to the right slice of data without duplicating roles.

Keeping it maintainable

Model-driven apps are serious software, so treat them that way:

• Build in unmanaged solutions, and deploy managed solutions to every environment downstream. Managed solutions are layered and removable, giving you a clean lifecycle.
• Put solutions under source control and deploy them through a pipeline, so every change is traceable to a commit and every environment is consistent.
• Move real logic to the server. When business rules outgrow what the designer offers, implement the logic as plugins or custom APIs so it’s enforced no matter which app, import or integration touches the data — and so it can be tested.

The payoff

Done well, a model-driven app gives you speed early and stability later. It is quick to stand up because so much is generated from the model, and it stays maintainable because the platform handles security, auditing and responsiveness for you. Most importantly, it is a foundation rather than a dead end: as the needs of the business grow, the same app extends cleanly with business process flows, plugins, PCF controls and Azure integration.

If you’re weighing up how to deliver a new internal application on the Microsoft stack, a model-driven app is very often the right first answer — and the discipline you invest in the data model and security is what determines whether it stays a pleasure to own two years from now.