Jun 18, 2020
When Model-Driven Power Apps first appeared on the scene, it brought with it a $40 per user license called Power Apps P2. Earlier this year Microsoft launched a $10 per App "Pass". Clearly $10 is going to get some eyeballs, along with a lot of skepticism about it having a place in an organization that may be paying $100 per user plus. So let's talk about it.
I believe it was at last year's MVP Summit; there was an off-site dinner for the bizapps crew. I saw Charles Lamanna, Corporate VP of the Low Code Application Platform, sitting at a table with an open seat next to him, so I snagged it. Charles is well aware of our RapidStart efforts, and has been a supporter since I first met him when he came on board the bizaaps team. At some point in our conversation, he leaned in a quietly and said they were working on something: "You are going to like it". He was vague on details at the time, but he clearly understands our RapidStart business model, so I got pretty excited.
I had a few "pick my brain" calls with the Microsoft team about the upcoming "per app pass" before it became public. I specifically recall asking, more than once, if they were prepared for "unintended consequences". The problem with "unintended consequences" is that they are not always easy to spot in advance, particularly if you have a filtered view. Microsoft is a technology company, and the Business Applications Group is made up of a lot of technology-minded people. A recurring theme seems to be their inability to view things through a business eye. This is how the Team Member licenses ended up being abused. To a technical thinker the Team Member seemed like a perfect solution to a particular challenge. To the business person on the ether end, it seemed like an excellent opportunity for exploitation.
There is a classic fable that this reminds me of: "A scorpion, which cannot swim, asks a frog to carry it across a river on the frog's back. The frog hesitates, afraid of being stung by the scorpion, but the scorpion argues that if it did that, they would both drown. The frog considers this argument sensible and agrees to transport the scorpion. Midway across the river, the scorpion stings the frog anyway, dooming them both. The dying frog asks the scorpion why it stung the frog despite knowing the consequence, to which the scorpion replied: "I couldn't help it. It's in my nature."
Microsoft often finds itself a Frog, dealing with customer Scorpions.
They will seek ways to exploit it. In our case we have taken full advantage, rebuilding all of our apps the be able to run on any license, but in particular, the $10 App Pass. I don't feel like we are exploiting, after all Charles did say I was going to like it. This kind of felt like tacit permission, even encouragement to head down this path. It's a two-way street, Charles also needed some ISVs to showcase this approach for other ISVs to consider this path as a great way to join the ecosystem.
The risk of cannibalization of the first-party applications was obvious, and not lost on the team. In one of my chats with Charles, I asked about this probability, he said: "I would say we are quite confident on the Microsoft side that the value and the intellectual property and the ongoing services and support and SLAs and integrations that come with the proper Dynamics applications can and will continue to command those prices." But just to be safe, they decided to toss a blanket over a few key entities and restrict them to the first-party apps. At the time there was, and still is, a lot of discussion about API limits across the stack, and the Per App Pass was given a pretty low limit of 1,000 per day. I had not liked the "Restricted Entities" idea from the jump. In that same chat Charles alluded to more Restricted Entities coming, but in a later chat with Charles, he conceded: "restricted entities as a concept are largely antithetical to our common data service, common data model and vision. And they were just like the least bad option to go make sure that we appropriately can license Dynamics apps." I had suggested a different approach in another post: "The real value of the first party apps is in the logic layer, not the data model.". While I'm sure my comment was not the trigger, it is the direction they are now heading.
So the "replacement" scheme for restricted entities is still being formed, but basically the vertical fences between certain entities, will pivot to a horizontal line between the first-party tables, and their proprietary logic. Where restricted entities was a quick and easy solution, this one will take a lot more work for Microsoft to execute. It seems proprietary logic is all over and pretty deeply wired. Will this be better? It's hard to say at this point. Where before we had some entities that could not be used, the other ones, that were not restricted, were being used... along with their OOB logic in many cases. So it seems like instead of pointlessly replicating entities, we will now instead have to create all of our own logic, and possibly our own forms, dashboards etc.. But, it seems completely fair to me. No one is entitled to get a Prime Steak for the price of a burger.
So what will this mean for your $10 app plans? Well, Microsoft giveth and Microsoft taketh away. Eventually, you can have a "no cliffs" scenario. The cliff I am referring to is starting with vanilla CDS and building some apps, and then realizing that the first-party apps have a lot of features that would like. Today, you cannot get from here to there without a migration. Not a "cliff" exactly, but definitely a hassle. This path will be cleared "in the fullness of time", where a simple license swap will be all that is required. Today, you can install the first-party schema on your vanilla CDS, it is available here on Github. As of now, even with this schema installed, you do not have a direct upgrade path, but the migration should be easier going from an OOB entity to an OOB entity, than mapping your custom one over. When the path is "cleared" will using this approach today just start working for upgrade later? Good question.
Depending on your use case, it is completely viable. We have developed many very sophisticated solutions on CDS with the $10 Per App Passes, even without utilizing all that is available to that pass. Mostly starting with one of our RapidStart accelerators, we have built Project Management applications, Field Service applications, Referral Management solutions, each of which has become an accelerator on their own. What will you miss out on? For many customers, they won't miss out on anything, again depending on your needs. Like Charles said, there is a lot of value in the first-party applications for those that need it.
We started with the premise that many customers just want something simple to use at the lowest possible cost. So we built our accelerators with the $10 pass in mind. You can start with a vanilla CDS, and many do. But many customers already have Dynamics 365, and a significant number of their users are making use of those high-value proprietary features. But not necessarily all of their users, particularly in larger organizations. A significant part of the work we are seeing today is taking certain use cases, building a specific app for those users, and dropping them down to $10 passes, sharing the same data as the first-party users. This tends to be an addictive motion. Is this cannibalization of high cost licenses? Yes, but I would argue that if a user can do their job with a $10 license instead of a $95 license, that makes the customer happier and less likely to consider a change in platforms.
Unintended consequences are not always a bad thing.