PowerApps licenses and a Dynamics 365 environment

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.