Understanding what customers can do with specific licensing options available for Microsoft Business Applications has become a key component of the solution design process. There can be many different ways to reach the same business goal when either customizing and extending first party apps that Microsoft has built for Dynamics 365, or leveraging the Power Platform for building your own custom apps. Even within Dynamics 365, when planning which specific features are taken into use for managing a specific business process, it’s important to keep in mind whether it requires some “premium” features available only in more expensive plans like Sales AI. Then there are of course the consumption based components used in Microsoft’s more recent additions to Power Platform licensing model, like API calls and Portals logins.
Some partners and customers complain that the licensing documents from Microsoft are far too long, but the reality is that at the same time they’re also not extensive enough. It is quite common to run into a scenario when planning the implementation of a specific solution for a customer and then not finding a definite answer on what licenses it requires exactly. This is particularly true nowadays when the licensing model is a merger of the Dynamics 365 style business application products and the new citizen developer focused offering of Power Apps and Power Automate. These different products share more technology underneath the covers than many people realize, yet the way they are sold and positioned is quite different. When there is overlap, that’s when confusion arises.
What would make it easier to validate the solution design against the licensing model is if there was a way to do test cases with a live system. Unfortunately much of this model still remains an honor system, meaning that many rules only exist on paper but have not been actually technically implemented within the online service run by Microsoft. However, we’ve been hearing about the plans for further technical enforcement of the licensing for some time now. In fact, there are pieces related to this that you can already see with your own eyes when exploring your environments.
Enforcement mechanism inside CDS
If you are keeping track of the weekly updates that Microsoft pushes into every Online environment (via tools like Solution History for XrmToolBox), then there’s a chance you’ve noticed a hidden solution called “License Enforcement” deployed in December 2019. This introduced a new “Service Plan” entity into the schema, as can be viewed via the Default Solution:
You won’t be able to do an Advanced Find search to browse through the data for this entity. There is, however, a very convenient way for us to do a query of the Service Plan records, again via XrmToolBox, by leveraging FetchXML Builder:
Wow, that looks interesting! While installing the solution, Microsoft also deployed a bunch of Service Plan records that presumably cover all the different types of licenses that have at some point in time granted access to a Dynamics 365 Customer Engagement Online environment, or CDS. Let’s copy this data into Excel for further analysis, and let’s make sure we tap the “friendly names” view option before doing so.
It looks like there’s important data in the columns “Display Name” & “Name”, but the really interesting column from licensing enforcement perspective is “Access Mode”:
Looking at the 4 options, it’s a bit difficult to understand what the difference between “all applications” and “first party and custom applications”would be. Even legacy products that are long gone like “Parature Enterprise” have the “all applications” access mode enabled. Without further information on this, let’s focus on the more straightforward options, like “first party applications”:
Not too many entries for this option. Also it’s not surprising at all that it is the Team Member licenses that show up here. If there is one type of license that Microsoft probably would want to undo in the history of the Dynamics product line, it must be this. Introduced back in the days of Dynamics 365 CRM + ERP story debut, its design neglected the power of the platform in the sense that it granted practically unlimited rights for custom entities for a very low cost. The rights included in Team Member have since then been restricted considerably, to make room for the actual platform SKU that is Power Apps.
Speaking of Power Apps, let’s look at the service plans that have the access mode set as “custom applications”.
A lot longer list, with again some surprising entries like “Exchange Foundation”. The vast majority of this list is however very logical, as it mainly covers PowerApps and Flow (which on the branding side have been changed to “Power Apps” and “Power Automate”, of course, but this is licensing). The twist here is that similar to how Team Member granted too wide access for custom app scenarios, the rights included in Power Apps for accessing Dynamics 365 CE data stored in CDS are also a bit problematic from a commercial perspective for Microsoft. What clearly is off limits is the use of the standard app modules that ship with the Dynamics 365 App licenses.
App Modules as a licensing construct
The whole point in bringing data like service plans inside the CDS database is in being able to link that into app modules. If you browse through the metadata of any Online environment you’ll discover an entity with schema name “ServicePlanAppModules”. The relationship between a service plan and the app module is both the way how Microsoft has crafted the licensing terms for different products and also the mechanism through which access rights for different license holders will be restricted in the future.
Looking at the fresh new Release Plan for Dynamics 365 2020 Release Wave 1, one of the new features is in fact called “License enforcement: users with new Team Member licenses”.
For Team Member licenses purchased during or after October 2018, license-based access will restrict users to a set of designated app modules. These users will no longer be able to access Customer Service Hub, Sales Hub, or custom app modules.
In April 2020 and already earlier in preview we’ll finally see the new Sales Team Member and Customer Service Team Member app modules that have been hinted at in earlier communication from Microsoft. Although these will be preconfigured modules, there will be room for customizing them to contain custom entities and (presumably) also hide unwanted entities – just like with traditional app modules. What will be different though, based the Release Notes as well as the Service Plan data model, is the lack of ability to build your own specific app modules from scratch. Any organization that has used Team Member licenses for covering a functionality not included within the first party Dynamics 365 Apps built by Microsoft will therefore have some work to do for redesigning the end user facing experience to accommodate these technical restrictions being put into place.
“Oh, but we don’t use Unified Interface, so I guess we can skip those app modules in the oldskool web experience, right?” Wrong, you have even more work to do! There will be no support for accessing the legacy web client after October 2020. You better hurry with both planning your transitioning to Unified Interface as well as addressing the gaps that may be left for your Team Members users that will not have access to Sales Hub or any custom app module. Both of these changes have been a long time coming, but as many surely have experienced, it can be challenging to get the necessary planning and development work prioritized within organizations without a hard deadline. Now we have one (well, two dates interlinked), so that part is solved already!
Restrictions like these enforcement rules are bound to generate some emotional responses. In the long run, having the rules specified in software rather than just paper should serve to bring more clarity into what services are available with which licenses. Any such clarity is most certainly welcome for making it easier to navigate an ever growing product stack like Microsoft Business Applications.’
Read more
Check out my blog post New Team Member apps for Dynamics 365 where I explore the 2020 Release Wave 1 early access versions of the new App Modules for Sales Team Member and Customer Service Team Member.
I don’t really get the idea of these designated app modules for team members, if you are allowed to customize them to full extend. Maybe it’s just a way to get people to make the shift from the team member licences to the Power Apps per app license.
However, making the switch from team member to Power Apps per app license (or per user), might be a bit easier, if Microsoft actually updated the ‘Restricted entities requiring Dynamics 365 licenses’ list which should reflect the licensing changes that were published in October 2019 🤷♂️
I am struggling to imaging how it will look & feel.
What I understand:
We will have a First Party App which can only be accessed with a big license and Sales Team Member App which can be accessed via big licenses and Team licenses.
The Team member app, can be customized, bit only entities & components which is unlocked for team member licenses, can be added to this App.
Does it mean, We have to build atleast the UI Twice? Because we must Strip off all „non team member subgrids“ from the Forms/Navigation?
I am a big fan of enforcement. This will bring more clarity to us.
Martin, I do indeed believe that this will have the unfortunate side effect of adding some app clutter, as you need to have those 2 different experiences at least. Then again, the way Microsoft is envisioning everyone to be using not just Dynamics 365 apps like Sales but also a number of Power Apps, I guess the number of different menu icons and navigation paths would inevitably grow higher.
It will be interesting to see how the “premium” features can be / will be restricted to specific App Modules in the future. Obviously this would be the valid reason for implementing the access control on this level.