Power Apps Potholes


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.

 

Steve Mordue MVP

Steve Mordue, a Microsoft Business Applications MVP, is the CEO of Forceworks, a 2014 Microsoft Partner of the Year. Steve started his business applications consulting career in 2001, originally supporting Salesforce.com as a Certified Consultant. Steve transitioned his consulting practice to Dynamics CRM, (now Dynamics 365) in 2011. Steve has been engaged in hundreds of deployments over the course of his career. As one of the leading Microsoft Business Application Consultants, recognized by Microsoft as an expert, Steve has provided training, on behalf of Microsoft, to other Microsoft Partners globally on how to launch and build successful practices. Steve is a member of the Worldwide Dynamics Partner Advisory Council, and is a frequent presenter and panelist at global Microsoft events. The opinions shared in this blog are Steve's alone. If you are looking for Microsoft confidential information, you will not find any here.

9 Responses

  1. Doug McLachlan says:

    Great article – completely agree that the most 1st party app value is in the logic layer (and perhaps increasingly in custom controls to a lesser degree). Rather than restricting entities why not license and restrict the app-specific logic and other value added components?

  2. Ali Khan says:

    Great article. Agreed – the value is in the logic or user experience, not the data model. In the context of D365 Field Service, for example, the value is in Schedule Board screen (that screen is in itself the USP for the entire Field Service solution) and not the entities behind it.

  3. Michael Dickerson says:

    Steve, your point about the data model is spot on. What’s more, having restricted entities would seem to defeat the purpose of open-sourcing the data model and ODI. First party apps have value because they cost much less than for a customer to build and to maintain….at least this is true for everyone other than hobbiest developers 🙂 Finally, the threat of restricting entities in the future makes it dangerous for ISVs to build on MSFT and scares people away. There is plenty of room for MSFT to grow platform and first party app revenues. Anything that creates mistrust is counterproductive to their own interests IMHO.

  4. Nigel says:

    “More Restricted Entities Coming… eventually” – based on analysis of usage telemetry in the same way MS chose which Flow connectors were moved from Standard to Premium. Don’t ya just love the cloud??

  5. Hakan Parlak says:

    Hi Steve, great article, thanks. One question regarding your article; if I create any restricted entity on CDS from scratch does it violate any licensing issue? Does Microsoft blocking us to create function such as “Customer Service” app on CDS?

  6. Matt Johnson says:

    Also, you can use a restricted entity in a powerapp, it’s (should be) just read only.

  7. John Hall says:

    It honestly makes it difficult to trust using any entity inside the CDS. The licensing maneuvering here makes it problematic for Architects to recommend the investment of time/resources when Microsoft is clearly still juggling the rules. And this is all happening before there is some kind of investor pressure to improve quarterly numbers.

  8. Niels says:

    Great post, Steve.

    I’m also wondering if Microsoft has second thoughts about this approach since the restricted entity list has been out-of-date since October 1. And since then new license guides for Power Apps and D365 has been published.

Leave a Reply to Niels Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.