Believe it or not, Dynamics 365 Customer Engagement applications from Microsoft are built on top of Power Platform. No, they didn’t originally start that way, but as the Citizen Application Platform technology from the PowerApps side merged with the former Microsoft Business Solutions product that was originally built to be an extendable CRM system, that is the end result today. As an example, Sales Enterprise is one type of Model-driven PowerApp, even though it carries the Dynamics 365 branding given to it by Microsoft. Yes, it contains much more functionality than what the low-code application platform of PowerApps provides app makers out of the box, but if you would use the SDK to extend it with custom code via methods supported by Microsoft, you could build something similar yourself (given enough development resources).
Model-driven apps like Sales rely heavily on Common Data Service, because not only does it serve as the single data source for the app, but also the place for all metadata. The solutions are made of components like entities, which have subcomponents like forms and views. The process of building a Model-driven app may start from the creation of the required components, or you might reference something that already exists in the CDS environment you’re working in. You then choose the relevant components in the Model-driven App Designer, arrange them into a nice Site Map for users to navigate through, publish your changes and your App is ready to be used.
PowerApps license + CDS + Model-driven App = ?
Although it may not be obvious, the CDS Connector included in paid PowerApps plans (Per App or Per User in the new world) allows you to connect to CDS environments that have been born from the provisioning of a Dynamics 365 Customer Engagement App. (Note: while there is a separate Dynamics 365 Connector, that has been deprecated in favor of the CDS one.) Using Dynamics 365 data in PowerApps for mobile apps and Flows for process automation is a very attractive scenario for many businesses and of course MS wants to promote that. As these effectively are part of the very foundation that powers Dynamics 365 first party apps, there are hardly any technical limitations as the tools become more and more natively integrated with one another.
Let’s get back to the Model-driven app building scenario. Assuming we have a CDS environment that contains entities installed by the first party Sales Enterprise app from Microsoft, would it be possible to pick the very same entities used in this app into a custom App Module built by and accessed by a PowerApps user with no Dynamics 365 licenses? The answer is yes. Building a “My Sales App” that looks almost like the app shipped from Redmond is allowed. This pattern of using entities and data from Dynamics 365 hasn’t been specifically forbidden by the PowerApps licensing documentation. You can read everything via PowerApps, and aside from the list of restricted entities, you can also create, update and delete data in any CDS environment.
Since official licensing documentation rarely addresses all the questions that customers and partners have, MVP Steve Mordue had to pick up the phone and call Charles Lamanna, CVP of CAP (Corporate Vice President of Citizen Application Platform, for those not familiar with MSFT TLAs). This resulted in an excellent and detailed article on what the intent and practice behind the latest Power Platform (and Dynamics 365) licensing updates is, so you really need to check out “Steve has another chat with Charles Lamanna”. Taken from the interview is the important part:
“So even in a Dynamics instance you can use the new per app per user license, that’s $10 for power apps, as long as you don’t use any of the restricted entities or any of the application IP, like a schedule board or something from field service. The piece of information that’s missing is that list of sales restricted entities as part of the new per app per user license, there’s a few more entities from sales that will be added to that list.”
OK, so there are some restrictions, by generally speaking a PowerApps user is a lawful citizen in the land that used to be XRM but is now called CDS.
Down to the details
Today there is very little technical enforcement of licensing in the online environments run by Microsoft. As I predicted in my previous blog post about the new consumption based licensing model, API restrictions are probably going to become more in line with what the paper agreements say. Similarly, we’ve been told already for quite some time that the App Modules available for certain user types would become enforced, too. Therefore directly accessing the Dynamics 365 for Sales app with a PowerApps only license probably isn’t ok, but following the above mentioned path of building a custom Model-driven app on top of these same entities and their common components should be within the spirit of Power Platform licensing. After all, they can be found in the Common Data Model specification already today (even though you can’t deploy just the entities without the Dynamics 365 app, at least today).
The one license that has seen most controversy already before is Dynamics 365 Team Members. It’s the “SKU earlier misused as platform license” that Microsoft has since then locked down by removing CUD rights to accounts and drawing the line on 15 custom entities per App Module. We’ve yet to see the Team Member specific apps arrive that licensing guidance documents have referred to, but now when the legacy web client will be gone in one year’s time and be replaced with the Unified Interface that runs solely on App Modules, that might be a logical moment for MS to introduce the locked down experiences for the users on the $8 Team Member license.
What’s the road forward for customers who’ve widely deployed Team Member licenses earlier? Well, one attractive alternative would be to pay an extra $2 and get them moved up to the PowerApps per App license at $10. I’ve covered the details in my blog post “Application/Platform Separation in New PowerApps Licensing Model”, in case you’re not yet familiar with this new world. There you are fully able to leverage the core entities like account, plus there are no limitations on the number of entities your Model-driven app can have. Heck, you can even have 2 apps and Portal access all for $10! Sure, you do lose the tenant wide rights to use multiple environments, but production CDS data is probably what these users mostly would work with anyway.
While no one likes a licensing model that keeps on changing rapidly, the point where we are now with these latest announcements is at least a bit more clear than the incomprehensible maze of rights and restrictions we had before. The Venn diagram I had to draw in “PowerApps Starter Plans Capabilities Demystified” article is now deprecated, as the PowerApps P1 plan is gone and so are the restrictions on app type (used to be Canvas only) and entity complexity (used to be no real-time workflows or plugins). The new $10 per App plan can run an app as complex as you like. If you are facing the restrictions that Team Members will soon have to live with, just configure a custom Model-driven app into the same environment, give everyone a PowerApps license (and go crazy with the $40 per User plan if you can afford it!), then carry on using the application platform you already have deployed.
Dynamics 365 is no longer the platform
One more thing. On the Dynamics side, there’s an interesting new restriction introduced with the October 1st 2019 licensing changes:
“Dynamics 365 subscribers may continue using PowerApps and Flow to extend and customize their Dynamics 365 applications. However, Dynamics 365 Enterprise licenses will no longer include general purpose PowerApps and Flow use rights. Dynamics 365 Enterprise application users can continue to run PowerApps applications within their Dynamics 365 environments, but running PowerApps applications in non-Dynamics 365 environments will require a PowerApps license. An additional Flow license will also be required to run flows that do not map to a Dynamics 365 application.”
If you used to think that by buying a Dynamics 365 CE Enterprise license you get an “Access All Areas” pass to the platform back stage, then this recent change gives some new perspective on how Microsoft actually thinks. In preparation of Power Platform becoming a much more widely used technology than Dynamics 365 CE or XRM ever was or could be, it looks like there’s a need to separate the two routes through which the platform consumption rights can be acquired. Different product teams will have different buckets for both licensing revenue and operating costs, so buying a $95 Enterprise App license for Dynamics 365 no longer entitles you to everything that a $40 PowerApps Per User license does.
Personally I don’t consider this environment type restriction to be a very elaborate way to define the licensing model boundaries. A Dynamics 365 customer today has a (near) zero costs associated with provisioning a CDS environment as a “Dynamics 365 environment” vs. a naked CDS environment for PowerApps, since they only pay per storage capacity and no longer per instance like the old Dynamics 365 licensing model used to work. To be compliant with the new terms and keep using PowerApps and Flow in any CDS scenario, all they’d need to do is throw in a Dynamics 365 App and never use it. Of course today you need to plan for this before provisioning an environment as you can’t (yet) add first party apps into a pure CDS environment afterwards. Anyway, details like this area bound to evolve as the related platform features mature, so the really important thing is to pay attention the direction of where Charles & co. are taking the big picture when it comes to Power Platform’s commercial model.
thanks for that information. I just received a question from a customer last week asking, if he’s able to use a CDS instance (or what ever you want to call it) in this environment where he has several Dynamics 365 CE instances running. I unfortunately still dont get what an “Environment” in that perspective means. The customer has one tenant with a few Dynamics CRM instances and wants to create a number of apps (which consists of model driven and canvas apps with flows). Can he do that under the new licensing changes? Or does he needs to aquire PowerApps licensed for all of the users who are supposed to use these new apps. Very irritating.
CDS environments are the same thing as instances were in Dynamics 365 land. If you go to Dynamics 365 Admin Center you’ll see all the CDS environments (with database) listed there. Similarly all Dynamics 365 instances should show up as CDS environments on the Power Platform Admin Center. Assuming the users have Enterprise App licenses, these would include the aforementioned rights to leverage PowerApps and Flow in scenarios that link to Dynamics 365 – as long as they “touch” that CDS environment. Keep in mind that Team Members or Professional licenses don’t have these rights, though.
That basically means, the customer sets up a new D365 instance (which basically is also a CDS environment) and adds entities/apps/flows as needed, all under his current licenses (Dynamics 365 – CE Enterprise).
I guess many customers will come across that question. Especially those, which are paying already a ton for Dynamics 365 licenses would want to leverage the CDS/PowerApps Platform to implement other solutions for other business processes.
Great post explaining how Microsoft sees the new licensing model and what to expect.
One question I still have is weather it would be possible to combine a PowerApps per App license with a Team Member license on the same user, getting access to let’s say a PowerApp that is allowed to use Universal Resource Scheduling. Do you have any thoughts on that?
Marc, I believe that once you acquire a Dynamics 365 app license, you gain the rights from within that app license to be used on a custom Canvas or Model-driven app. Now, as for Team Member, I wouldn’t rely on that to provide much additional features that a PowerApps license didn’t already cover, but knowing how funny the license barriers sometimes are, I bet there are scenarios where even this combination might be a valid option.
per app plan. How does that work for an app in the ALM? Must a user really be licensed per app for dev, test, pre-prod and prod? Or in likelihood are users who need this ALM access likely to be D365 Enterprise app or PowerApp per user plan holders anyway?
Is a below scenario possible?
1. Customer buys “PowerApps per user plan” licenses
2. model-driven apps are built and used by busines users
3. after few months customer decides that they want to extend their custom model-driven app with Dynamics 365 Customer Service Enterprise capabilities
4. Customer buys Dynamics 365 Customer Service Enterprise USL
Question: can we add the Dynamics 365 Customer Service App to the existing PowerApps environment?
Today this is not possible. The long term intent of Microsoft is to make this type of upsell possible, because why turn down good money from customers? Eventually there will most likely be a way to install Dynamics 365 apps on a “naked” CDS environment. Similarly, the whole Common Data Model concept isn’t very practical unless there’s a way to take the CDM schema from GitHub and deploy just that into CDS, without acquiring the first-party Dynamics 365 apps. The technology isn’t ready yet to allow this, unfortunately.
@Jukka, has anything changed in this area? Is this still not possible?
Nothing new, unfortunately. Microsoft still hasn’t been able to offer customers the “upsell” path for deploying the missing Dynamics 365 platform solutions after an environment has been created with just the Power Apps / Dataverse bits.
Hi Jukka – Thanks for the informative article that spells out the practical ramifications of the licensing changes. I was wondering if you could help clarify a point for us. When we set out to build a highly customized platform that wasn’t related to sales, marketing or field service, we purchased one CE license to provision the environments. Then we built a model-driven app and had Team Member licenses accessing that app.
In this new model, do we still need that one CE license for the environments to be active or can all of our licenses, including the ones we use to customize entities be PowerApp licenses?
Victor, that’s a good question. I can’t immediately think of reasons why the Dynamics 365 license would be needed for any customization work, but I would be inclined to keep it there “just in case”. The reason being that we don’t have very clear guidance from Microsoft on these type of cross-product scenarios. Since MS is clearly working towards making Power Apps and Dynamics 365 two different offerings and developing technical enforcement of the licensing model to make this a reality, there may be some components in your current solution that might later be defined as being of Dynamics origin.
Great Article. I have asked many people this question, reviewed licensing guides and have had cases with Microsoft and not getting a clear answers. My thought was If I assign one CRM license and then provision the CDS that has all the CRM entities in it. Can I then build a model driven app that has complex entities such as lead and opportunities in it. I would then only need to assign powerapp per app plan for other uses to use this app. Could I then remove the CRM license that provisioned the environment and assign power apps per user license instead, which would be required to administer the CDS environment, setup users, etc). I realize that currently, if I needed to add restricted entities into the app such as case or goal that I would not be able to do this