If you use any of the new Microsoft solutions/apps for Field Service, Customer Service, PSA, or marketing, you will notice some new roles appear in your security role list that contain the works “app access.”

We’ve discussed all of the reasons that model-driven apps may not work correctly for users. The most common reason is that the user doesn’t have a security role with access to the model-driven app.

While you can grant any role to any app, this gets messy. If you give one of your primary roles access to an app, you are giving everybody with that role access to the app.

If you are going to deploy numerous apps, you will find yourself in situations where you want to grant access to the app to selected people, and not everyone.

The beauty of the app access role design is it lets you easily control access to the app without modifying your primary security roles. You can simply add the Field Service app access role to any user to make the Field Service app show up in their app list, and you can remove that security role to make their access to the Field Service model-driven app disappear..

You also may want to follow this design pattern for your custom model-driven apps. Say you are deploying a bank teller app–simply create a blank role called Bank Teller app access, then only assign this role to the app (other than System Administrator and Configurator, which don’t count).

Then for every user for which you want enable access of the Bank Teller model-driven app, simply add this role.

***Note–remember that this grants access to the app, but does not give them access to dashboards and data components in the app.

Summary: Separate app access and data security for maximum flexibility.