Model Driven Apps

Model‑driven apps provide users with access to a set of related tables and functionality. They are a core part of how solutions are structured in Dynamics 365, and choosing the right type of app is important for long‑term flexibility, usability and maintainability.

Use out‑of‑the‑box apps first

Start by considering whether an out‑of‑the‑box (OOTB) Dynamics 365 app already meets the user need. These apps include built‑in experiences such as the Copilot Workspace for multi‑session working or Dynamics 365 Contact Centre for telephony and webchat scenarios.

Using OOTB apps has several advantages:

You get Microsoft’s supported multi‑session experience which cannot be achieved using a custom model driven app
New features and platform improvements are delivered directly by Microsoft without extra work
You avoid blocking or missing out on upcoming functionality by building a custom app that does not support it

If your use case aligns with a standard capability area, such as case management, contact centre operations or multi‑session workloads, then use the OOTB app unless there is a clear reason not to.

When to use a custom model‑driven app

A custom model‑driven app is more suitable when users need a simple, single‑session interface with a streamlined UI. Custom apps give you:

More control over navigation and screen layout
A clearer experience focused only on the tasks the user needs
Lower risk of unexpected changes when Microsoft releases new features

The trade‑off is that you take on more responsibility for ensuring users still benefit from platform improvements. The right choice depends on the complexity of the scenario and how much you rely on Microsoft’s multi‑session or advanced features.

Avoid creating duplicate apps

Model‑driven apps should be aligned to functional capabilities, not individual teams. Where multiple teams work with the same tables and processes, they should use the same app.

Avoid creating several copies of an app just to give teams versions with team‑specific names or branding. This leads to fragmentation, duplication of effort and inconsistent user experiences. Instead:

Build the app once around a shared functional purpose
Use security roles to control what each team can see and do
Create tailored views or dashboards inside the shared app where needed

This keeps the system coherent and easier to maintain.

Apps should reflect common capabilities

A model‑driven app provides users with access to a defined collection of tables/capabilities. When designing your app structure:

Group tables that belong to the same capability or business process
Avoid spreading a single capability across multiple apps
Review whether existing apps already expose the tables your solution uses

This ensures users have a logical, task‑focused user experience.

Best practices

Keep navigation simple
Use clear sitemaps with logical groupings, avoiding unnecessary areas or clutter.

Reuse before creating new
Before building a new app, check whether an existing one already provides the functionality.

Design apps for real user journeys
Structure navigation and forms around how users actually work, not how the data model is structured.

Limit the number of apps in the environment
More apps mean more complexity, more maintenance effort and more training overhead.

Align with Microsoft roadmap
When Microsoft is investing heavily in an area (such as multi‑session, case management or Copilot experiences), prefer OOTB apps to benefit from future updates.