Model driven apps are a user interface layer on top of a Dynamics CRM for Sales database or a Common Data Services database (Both these databases are quite similar, the main difference is licensing). This layer affects which forms, views, and dashboards are available to them. Basically, it controls the menu navigation around the core database and lets you tailor the user experience to only the necessary items.

Multiple model driven apps can share the same data. So a user entering an account in one model driven app can be using the same account list used by another model driven app. If you have multiple environments – like and production and sandbox environment – then the model driven app uses the current environment database. This is handy for working on updates in a test environment and then transferring the updates into production.  A user can have access to multiple apps and can switch freely between them.

Items that can be different between apps:

• Dashboards – which dashboards are available
• Forms – which edit forms for an entity/table are available
• Views – views on grids/lists for which views are available
• SiteMap – what appears in the navigation menu

Example of navigation menu difference in the stock model driven apps:

Sales Professional

Sales Team Member

Customer Service

So why build a model driven app? It can streamline the user experience in CRM. You can tailor the navigation menu to only the areas of CRM that you are using. For an organization with multiple roles or departments where each role/department wants different information easily accessible this can help de-clutter the interface for the user. You can keep the sales views and dashboards available to the sales model driven app and keep the support views and dashboards available to the support model driven app.

How does that work with security? Security is still a key piece of CRM. If a model driven app puts the accounts on the menu but the user has not been given read access to accounts, they will not be able to access the account area. Security is shared between all apps, so a user granted access to accounts, has access to accounts in all model driven apps. A model drive app is assigned a security role itself so you can manage which users have access to which apps.

When you create a new CRM environment, Microsoft installs a few model driven apps by default. The main ones are “Sales Team Member” and “Sales Professional” and “Customer Service Hub”. You can customize these apps and create new ones. I have found however, that user licenses do affect what is available. A user that only has the similarly named “Sales Team Member” user license can only access the “Sales Team Member” app – Microsoft enforces this in the background and does not explain it well in their documentation. The same is true for the “Sales Professional” app with the “Sales Professional” user license. Once you get to the proper user licensing level, then you are able to build completely custom model driven apps on top of the stock ones provided by Microsoft.

It’s not uncommon to have just one model driven app for everyone to use. I think one of the best usages though is to de-clutter when lots of forms, views, and dashboards accumulate. For example, on the account list there may be several views created for the sales team to keep accounts separated by territory. The customer service team may have no need for these views and has their own set of views for accounts. The account view lists may become quite large and is a nuisance to constantly scroll through to find the view that you need. Creating a model driven app for each team can hide these unneeded views and leave just the views that team needs. That streamlines what the user sees improving their CRM experience.

Other posts on the subject:
https://powerapps.microsoft.com/en-us/blog/introducing-model-driven-apps/
https://docs.microsoft.com/en-us/powerapps/maker/model-driven-apps/model-driven-app-overview