There are a couple of different ways to approach building a Power App... and I am not referring to Canvas vs. Model-Driven here, but rather, the environment type. Today, you can build a Power App on either a "vanilla" CDS environment, or on a Dynamics 365 CDS environment. Why does it matter? Vanilla Let's quickly discuss the Vanilla approach as it is the safest, which I will explain why later. If you log into the Power Platform Admin Center you will be presented with a list of Environments...
There are a couple of different ways to approach building a Power App... and I am not referring to Canvas vs. Model-Driven here, but rather, the environment type. Today, you can build a Power App on either a "vanilla" CDS environment, or on a Dynamics 365 CDS environment. Why does it matter?
Vanilla
Let's quickly discuss the Vanilla approach as it is the safest, which I will explain why later. If you log into the Power Platform Admin Center you will be presented with a list of Environments that you have in place. If you have Dynamics 365, any of those environments will also be listed, otherwise these will all be what I call "Vanilla" environments. Clicking on the + New button, will start you on a path of creating yet another Vanilla Environment. If all you have is Power Apps licensing, then all of your environments will be Vanilla.
What is Vanilla?
A Vanilla CDS Environment will contain a basic data model, including Contacts, Accounts and few other items. It is meant to be extended by you to meet your needs for a Power App you want to create. It is a perfect solution for moving a Speadsheet based process into a "real" app. Or for possibly replacing some basic point solutions. But what if you also have Dynamics 365, and want to build a specific limited purpose app using the data that resides in that Environment?
Apps on D365
Dynamics 365 CRM apps are basically just great big Power Apps. You could build your own app, to do something particular for a certain set of users, and it would appear in the App list, right next to Enterprise Sales for example. Why might you consider this? Let's take an example of a part of your business that uses Dynamics 365. Let's say this department uses the Contacts and Accounts entities, but it also uses a few custom entities that you created for some specific purpose. One reason to consider building a Power App is that you can create a highly targeted application just for those users, that includes only what they need, and nothing more. Another reason is that you could potentially reduce your licensing costs... significantly.
License Tightrope
When you build a Power App on top of a Dynamics 365 environment, you have access to all of the entities in that environment, including of course any custom ones you created. If you were to pull into your app Contacts and Accounts and your custom entities, you are potentially creating an app that could run on a $10 App Pass instead of a full user license. But if you also decided to pull in the Case entity, for example, you would see a message that this entity is restricted. You can still use it, and it may still make sense to create a targeted app for some purpose, but you will not be able to use the lower cost licenses for these users.
Restricted Entities
Some of the entities that are in a Dynamics 365 environment are "Restricted", there is a list of them here. Why are they restricted? Microsoft has given you the ability to build a Model-Driven Power App, ostensibly, to build simple apps. However, there is no limit on how complex your app can become, it is only limited by your knowledge and ability. With a much lower cost, many are taking a hard look at how they are using the Dynamics 365 apps, and some are opting to just build their own "Sales" app for example. Not only can they eliminate all of the features they are not using with a skinnier app, but they could potentially reduce their license costs, as long as you avoid the Restricted entity trapdoors.
More Restricted Entities Coming... eventually
Microsoft announced in October, and Charles Lamanna confirmed publicly on my podcast in September, that more entities will be tagged as restricted. But as of today, we still don't know which ones. Meaning we have been building within the boundaries, but at some point the boundary will be moved. That will not be a good day, if something that we used, suddenly gets tagged as "restricted".
Why Restricted?
Microsoft needs to protect their first-party app revenue, this is understood and reasonable. If I had P&L responsibility for one of the first-party apps, I would be concerned about Power Apps cannibalizing some of my users. But restricting access to a few random entities is a bad way to approach that. Previously there was a rule that you could not "replicate the functionality" of the first-party apps, but they removed that rule so Power Apps would not die a quick death. So, while I can't use a restricted entity in my app without triggering a higher license cost, I am free to build my own custom entity, right next to the restricted one and use that. So is this the perfect solution? Well, that depends on the trajectory of the customer. If at some point in the future they want to move to the full first-party apps, and have been using a custom entity for some OOB feature, they will have to migrate data. Or, if they have a mix of users, some on first-party and some on a Power App, this would also be problematic. So the restricting of entities does not protect the first-party apps, it just creates future frustration for customers.
A Better Idea?
As I was writing this post, a fellow long-time MVP floated the same idea I was planning to write here. Basically the value of the first-party apps is not in the data model, as I said I am free to replicate that, and it is not even hard to do. Protecting an app by creating a potential "pain in the ass" scenario in the future is not a good idea, as most customers will not realize that until later. The real value of the first party apps is in the logic layer, not the data model. In particular where Microsoft has made some proprietary logic part of their app. Also, app specific features like plugins, or behind the scenes processes like Lead qualification, or SLA management. These are things that are not only valuable, but more difficult to replicate. If I were able to use a restricted entity, like Case for example, I would have no reason to create my own. If at some point that customer wanted to move up to the full Customer Service app, it would be a simple license swapping process, instead they may consider staying put, if the hassle is too high. This would be the opposite of what Microsoft's first-party teams would like to see happen. I have customers in that very predicament right now.
Restricting entities was a down-and-dirty, lazy way to solve this problem. Hopefully Microsoft will come up with a better approach soon.
