When should you use App Modules?

One of the questions I get frequently is "Hey Dave, when should I use the App Module feature of Dynamics 365?"

First, let's talk about what are app modules. To explore that, let’s first remember that without app modules CRM offered a single navigation definition and many other things trimmed by what the user's security role or access was. An example of a glaring omission from that are views that had no easy way to role tailor them. Tailoring of this "Kitchen Sink" experience was often done by a series of compromises or introduction of complex custom dev to handle what should be simple scenarios. After all remember, a distracted user by things they don't need to see is a less productive user.

App modules was introduced along with Dynamics 365 to allow creation of more purpose defined sets of application assets. What do I mean by that? Well imagine if you had someone that all they did was collect leads - you could create a lead collection app that only had the specific assets they needed for lead collections added to it. This app has its own navigation (sitemap) and specification of what entities, forms, views, dashboards and even business processes that the users of the app will see. These app modules are surfaced in Home.Dynamics.com and become peer level applications to Sales, Service, Field Service, Project Service. They also are peer level to PowerApps in the web client.

Prior to 9.0, these apps were only visible and useful in the web client because the Dynamics 365 mobile applications had no concept of surfacing the applications. This changes in the 9.0 release where now the mobile application can surface one or more applications that the user has access to and allow them to switch between them. In fact, an app module is REQUIRED to be created or assigned to allow a user to use the mobile application. So, as of 9.0 any project deploying mobile will need an app. Another enhancement to app modules in 9.0, was the ability to connect an app to an offline profile defining what data users of that app need to be able to take offline.

The 9.0 release also introduced a new user experience referred to as Unified Interface. This new framework co-exists with the existing web client experience. App modules was enhanced in 9.0 to support creating apps that were targeted to the unified interface clients. That means when you create an app, you pick if it is a web (legacy UI) or unified interface. Notice I said "or" because as of this writing you can't have one app be targeted to both. You also don’t have a way of saying this app is only for mobile or this app is only for browser use. Now keep in mind, as of 9.0 the unified interface is supported for use by mobile, but not from the web client as it is only in preview for the web client. This means if you want to deploy a 9.0 app, that is used by both mobile and web users you would need two apps. The easiest way accomplish this is to have a solution that contains all your assets, then create the unified interface app, and then create second app targeted to web and start from that solution. When you do this it will copy the site map and add just the solution assets to the second app. Going forward you would still need to maintain both. The other thing to keep in mind if you create a web and a unified interface, with the unified interface being for mobile only, you don’t have a way to keep web users from being tempted to launch the unified interface app from the web client which technically isn't supported! Confusing? Yes, but hopefully, this two separate apps is a temporary need as eventually everything will move to unified interface.

Apps get a unique url and a unique app id. The url currently however is not as user friendly as you might think. For example instead of something like ..crm.dynamics.com it is more like .crm.dynamics.com/apps/. Now I don't know about you but I don't know many users that will ever remember that unless they shortcut it or add it to favorites. There is probably some DNS magic you could do to help, but hopefully in the future we will get real custom urls for each app. Also keep in mind that if you are using any direct urls to the application that the AppID must be taken into consideration as part of the urls you build.

Let's talk about security vs. apps. It's important to note that just because you might only put two entities in an app, that doesn't mean that is all the user has access to. Things like advanced find would still allow the user to explore more entities that their security roles give them access to. Now they would do that via the default application labeled Custom (sidebar: Custom is a terrible name, you can change that via System Settings. I recommend if you are going to keep using the default app that you give it a user friendly name like "CRM" ) Now back to access, users also can still access via workflows, and even the Web API if their security roles give them access. Therefore, think about apps as providing focus, not implementation of security requirements. You can, to again provide more app focus, disable the custom (default) app so users can't see it. But key thing to note there, they still seem to be able to access it via the direct url that is hard to obscure from the users. So the real value of disabling the custom (default) app is simply to reduce the clutter they see in their app list.

So that is a lot of preamble to get to the original question of “when should I use app modules?” The simple answer is I believe we are close to where just as you create a custom solution for a project you would also create one or more app modules as well. Similar to how you consider for a project do you need one solution or multiple, you will do the same thing with app modules also. That decision should be guided by packaging a set of related assets that users would need to complete one or more "business transactions". That could be as simple as one or two entities for a small app, or a full set of items like you would have if you accessed the Custom (Default) app module today. That said, you can certainly go "app crazy" and create too much fragmentation. A core principal is these are supposed to help users not confuse them or require them to bounce frequently between apps to complete their work. Use similar thinking to how you would decide to create additional forms that are tailored to users via security roles. In many cases, role tailoring individual components is no longer needed as you can accomplish the same thing at the app level. That means you might have a Custom Sales App, and a Custom Service App that are role tailored but include some overlapping assets but provide a tailored focused view of a subset of the overall features and data. In the end, it is probably important to note, no matter how many apps you create, there is still a single data store, and API that is shared across all the apps. So apps do not provide any data segmentation, just a more focused user experience.

Apps offer a powerful way to provide a very purpose built focused experience for a set of users. They are a key part of the going forward user experience. If you haven't created your first app module yet, stop everything and go give them a try.