Why Power Platform licensing is complex, part 3: light use scenarios

In this series we’ve talked about the complexity that arises from how Microsoft defines (and re-defines) their product structure, as well as the concept of multiplexing where indirect usage of software (or data) needs to be licensed just like direct usage is. In this third chapter it’s time to look at the varying depth of software usage and how the licensing models out there don’t always take this into consideration the way people would expect them to.

“I only need to do X, why do I have to pay full price?”

For any business application deployed within an organization there’s bound to be a group of heavy users who spend a significant share of their working hours using the broad range of features offered by it. They might be administrators of a process that is managed with this app, or users whose tasks are either handed out via the app or facilitated by the information that the app can provide them. A service technician might have his or her day planned out in detail via Dynamics 365 Field Service. A salesperson could be using customer information and activities to keep track of their pipeline and prioritize actions via Dynamics 365 Sales.

Then there are those employees whose roles aren’t primarily focused on the aforementioned processes but who need to participate in them in some stage, or consume the outputs from these processes as one ingredient of their work. It might be merely signing off on an approval or completing a task that has been generated from the end-to-end business process. Again we could use here the same example as in Part 2 where merely submitting a new lead via a web form that has fully automated connectivity with Dynamics 365 will mean that these employees must be equipped with a type of license that would essentially allow them to also work with the lead qualification process of an full-time inside sales role. Hmm, why are these two very different personas treated the same, when one is a very light touch scenario and the other a heavy use of the system?

Whether you perform the task once a year or a hundred times a day doesn’t make a difference, due to the way how these business applications licensing models are constructed. It’s not a consumption model where you’d pay for the number of events and computing capacity like in Azure, rather it’s all based on purchasing the rights for a specific user to access feature X in the application. Underneath the app UI there is of course the same Azure technology being consumed to keep the bits running, but products like Dynamics 365 are quite a thick value-add layer of SaaS on top of it that removes the need for you to pay for the infrastructure. Similarly it removes the need for a custom software development project to manage your sales process, as an example, because you can simply subscribe to the Dynamics 365 Sales product and gain access to all of the business logic, UI, security models, auditing, APIs and numerous other features you’d eventually need for your digital business to operate in a sustainable way. You get a lot, so it’s only fair that it should cost something, too.

Still, it’s very common to run into a scenario where the idea of licensing every actor involved in the business process with the same flat monthly fee just doesn’t feel justifiable. In the Dynamics 365 world it might involve working with a single entity that’s not covered by the Team Member license. On the Power Platform side it might be a Flow that would need to do one step that inolves a Premium connector. All of a sudden the cost of allowing users to touch these tools might multiply the monthly fee, just because of that one thing. Couldn’t we, you know, just make that one thing be excluded from the Premium category and solve this dilemma?

Virtual borders vs. platform unions

It’s not like Microsoft wouldn’t be aware of the issues with these functionality borders and how they end up blocking many otherwise valid scenarios for leveraging their software products. Obviously there could be more money to be grabbed from the table if only there was a suitable licensing card to be played in these occasions. The problem is that every customer’s problem tends to be slightly different. Moving one feature checkbox from this license type to that license type isn’t therefore the answer. It would be like trying to adjust the borders of a country to follow a slightly different pattern so that you could optimize where you live, work, shop, go fishing, use medical services, and so on. A border will by definition limit your freedom in some ways, in exchange for offering you rights to (hopefully) exercise your freedom within the area covered by it. You gain some, you lose some.

In an interview by MVP Steve Mordue, Steven “Guggs” Guggenheimer described these light use / light touch scenarios and the licensing demands around them as “the most complex thing you’ll ever see”. Be it Dynamics 365 or Office 365, there doesn’t seem to be a satisfactory way to draw a line between heavy use and light use for the software products because when it comes to licensing everyone wants both A) simplicity and B) flexibility, which are C) a paradox.

There is a collective challenge, which is how do you build a licensing framework where you can’t tell between the two, light touch or light use, or you can tell but there’s no consistency. If I ask the question, “What does light touch mean to one ISV or light use?” I’ll get a very different answer than what I get from another one, so you can’t design a licensing type that works for everyone.

Looking at the evolution of Dynamics 365 products that used to be called CRM, then Customer Engagement and now “Model-driven apps in Dynamics 365”, they’ve been moving towards an “á la carte motion” where instead of subscribing to the whole software suite (Plan) you instead buy individual Apps. While initially this might sound like something that addresses the aforementioned customer pain points, I believe it’s mainly aimed at allocating the revenue more accurately between Microsoft product teams (and thus creating clear incentives for new product development) rather than making Business Applications less complex for customers to license. After all, you’ll often still need to buy a minimum of one Enterprise app at a list price of $95 per user per month, which isn’t exactly a figure that’s a great fit for the light use territory.

The platform SKU, meaning Power Apps Per User Plan, is closer to solving some of the challenges for customers that are ready to consider broadly licensing their work force for the business application platform rather than individual apps. Sure, a $40 list price is still more than Microsoft 365 E3, for example, so not an insignificant cost by any means. The more app scenarios you can cover in your organization with that flat platform fee, the cheaper it becomes. The first time you need to cross the border to the Premium territory it’s still a costly visa to acquire, but the more you travel the cheaper the relative investment becomes. You could compare this to a political and economic union like the EU, where benefits of having a single market that allows free movement of people, goods and services can outweigh the cost of forming and running this union. The application platform opens up opportunities by removing some (but not all) borders for your organization’s employees to participate in the digital processes runnign on top of it, regardless of if it’s just an occasional holiday trip to the neighbouring business unit or a permanent role of deep co-operation.

Alternative pricing methods

The Power Platform today requires you to purchase a license for each internal user, but there already is a mechanism available that would in theory allow paying for the actual usage. It’s the new pricing model of Power Apps Portals, where instead of buying the Portal application itself you purchase capacity to be consumed by the usage of the portal. This covers unauthenticated usage like page views, which isn’t all that relevant for real business application use cases. However, the concept of paying for each login of an authenticated user would be very applicable to many light use scenarios with infrequent but still valuable application usage.

The beauty of a consumption based pricing model like this would be that you wouldn’t need to purchase a full licenses for each and every user that might or might not use the system during any given week. However, when there would be a valid business need for them to access the system and use some of it’s features, they could be assigned a “day pass” that grants them the license for a 24h period. If on the next day they again need to do the same thing, it’s a new pass to be consumed. Doesn’t this sound like exactly the sort of a mechanism that could…?

Unfortunately as of today there isn’t yet a way for customers to purchase these type of day passes for their internal employees. The Portals licensing model is limited to only external users, whereas internal users must be assigned either a Power Apps license or an applicable Dynamics 365 App license (note: Team Member license does not apply here). There is some irony here because the per-login pricing model is actually making Portals a tough sell for some of the intended external audiences. Buying pre-paid packages of login capacity that would cover you entire potential user base of customers that might or might not log in to your public website can quickly become so costly that it makes more commercial sense to build a custom portal with custom integration into CDS instead of leveraging this product capability built by Microsoft (at least with the list price).

Regardless of these current challenges with aligning the license terms, I do believe the roads in Power Platform are eventually leading more and more towards the model of licensing by consumption. Not as the primary mechanism, but as something that will complement the user based licenses. This is because ultimately the goal should be value-based pricing. How do you measure the value generated by the business applications that are running on your shared cloud platform and used by millions of people out there for their own specific business processes? Well, the usage of the software products is a nice concrete way to gauge the potential sources of value – as well as idetifying places where the value is certainly not being captured (due to lack of usage/adoption).

In the on-prem era where some of the enterprise software licenses practices we still see today were originally drafted, you were selling a big system that the customer would acquire the server & user licenses for and then deploy the whole thing behind their own firewalls. The cloud has changed this model whereby the SaaS vendors are now able to see in much more detail the metrics for active usage (DAU, WAU, MAU) from the customer environments running on systems that they operate. In addition to ensuring that the customers keep renewing their subscriptions, access to this usage data also opens up possibilities for offering alternative pricing models that would make the many light use scenarios more attractive for large pools of potential users. The example of charging for app access by every 24h may not be the model that will be offered to internal users, but at least it represents a much less complex mechanism for customers to digest than the earlier models of drawing licensing lines between entities, features or access types.

Other parts in this article series can be found here:

• Why Power Platform licensing is complex, part 1: products
• Why Power Platform licensing is complex, part 2: multiplexing
• Why Power Platform licensing is complex, part 4: the role of CDS