It has now been five years since a major revision was done on the Microsoft Power Platform licensing model. The October 2019 rules not only introduced completely new SKU’s (read: license types) to purchase. They also described the future intent of how aspects of the platform use would be priced in the future.

Today is a good day to reflect on what the impact was from the October 2019 licensing wave. Although smaller adjustments have been made along the way, no similar earthquakes have shaken the foundations of Microsoft’s low-code and business applications. Nevertheless, I’ve witnessed many fellow professionals in the Power Platform ecosystem develop a fear of constant licensing updates and general distrust towards how MS handles the factors related to platform licensing costs. In this text I want to dive deeper into analyzing what the reasons behind this phenomenon are.

Being just commercial terms of what is the cost of software capabilities offered by a cloud service provider, licensing isn’t inherently good or bad. It should be merely about setting the price level, then watching demand increase/decrease and the revenue stream of MSFT changing as a result. In practice, there can be a surprisingly deep emotional response to such cold, hard business parameters. These are not just about the price, but rather almost entirely about how the licensing model and its changes are communicated.

The title of this article refers to FUD (Fear, Uncertainty, and Doubt). I believe that the tactics and communication policies MS has chosen to apply in licensing related questions have led to unnecessary damage in both product sales as well the ability of customers & partners to put their purchased software into effective use. The narrow and slippery licensing path on which one would need to proceed towards a higher adoption ground is a journey that many are rightfully afraid of.

Whether some of the FUD is intentional, that is a valid question to ask. Given how Microsoft has their very own entry in the Wikipedia article on FUD. That refers to a whole different era of software business, though. My interpretation is that the intentions behind the product strategy for MS BizApps licensing have been good, yet there are some unfortunate outcomes resulting from the legacy business models that cannot be easily erased away.

Let’s look at the two main categories of licensing terms that were launched five years ago and analyze what the result has been: app licensing and capacity licensing.

Licensing per app

As Power Apps & Automate (previously PowerApps and Microsoft Flow) merged with the XRM side of Dynamics 365 to form a single platform, some changes had to be made to the commercial offering. Early Power Apps customers had mostly begun approaching the low-code apps from the Office 365 perspective, yet now it was time for them to grow up into proper business applications that weren’t just about extending SharePoint lists and automating emails.

The old PowerApps P1 and P2 plans were replaced with Per App and Per User plans. Before, the differences between cheaper and pricier plans were about the complexity of the apps. Now, the model was simplified in the sense that only the number of apps mattered - not the technology used in them. I explored the details back in 2019 in my blog post, which I had to revisit to remind myself of the ancient world 5 years ago.

Erasing leftovers from the past PowerApps licensing model turned out to be mission impossible for the ecommerce system that Microsoft uses for online transactions in direct customer purchases. A year ago, I wrote about how despite repeated attempts to get attention on the clear errors, as a Microsoft MVP and partner, I couldn’t reach anyone who could have fixed the incorrect product feature information listed in M365 admin center. Today, it has been 5 years, and nothing has changed, meaning what I wrote about the misleading Power Apps product information is still true:

This reveals one source of uncertainty in Microsoft’s licensing game: how can you tell if the information you see is still valid? Thanks to the constant changes in not just licenses but also product names, articles both from MS as well as the community become outdated faster than most people can learn how the rules apply in the real world.

Anyway, back to the app licensing model. The idea of having a cheap license available for those customers who were only starting to explore the idea of using Power Apps with premium features (3rd party APIs, Dataverse, and so on) was a good one. It was obvious that customers weren’t yet lining up for purchasing an “all-you-can-eat” platform SKU, before they had validated its fit for purpose in some actual business application developed to solve their specific business problems. Start with one premium app, then just grow from there! Easy - right?

As it turns out, the only easy thing about Power Apps Per App licenses was purchasing them (if you ignored the above-mentioned misinformation in M365 UIs). Managing Per App licensing usage was, and largely still is, a nightmare. Because of the way they were treated, not as a license tied to a specific app nor a specific user but rather as capacity, it became impossible for admins to see who was using what & how many licenses were needed.

The result was that even though the price point of the Per App license might have been attractive for the business, the admin overhead meant that the professionals in charge of driving their usage (be it consultants or customer admins) weren’t exactly eager to promote the Per App option. The risk of buying a pack of Per App licenses and then allocating them to environments, without being able to ensure that they get applied to those users & apps you intended them for, was just the perfect way to erode customer trust on the platform management capabilities.

Five years ago, I made the prediction in my blog post that aligning the Power Apps licensing terms with the technical reality of the underlying platform was going to be tough:

As often happens, I was right. Two years later, Microsoft changed the model into a Per App license only giving you rights to one app (believe it or not, it was “~1-3 apps” before), while simultaneously decreasing the Power Apps plan pricing by 50%. Making the license and technical app constructs be closer to 1:1 allowed for some level of admin reporting to be revealed to users in the Power Platform Admin Center in the end of 2022 - three years after the commercial SKU was made available.

Capacity based licensing

If you think three years is a long time for selling cloud software under licensing terms that are impossible to compare to the actual service usage of paying customers, think again! Because we’re about to step into an area of the October 2019 licensing changes that is still waiting for official metrics to be made available:

We’re talking about setting a limit on API calls, also known as Microsoft Power Platform request limits. Basically, everything you do within the platform, be it opening pages in an app, running actions in a cloud flow, or doing code-based integration via the SDK, burns API quota. Up until 2019, it was assumed that this usage was covered by the user licenses for Power Apps, Dynamics 365 and other products. Then, Microsoft made the statement that if you’re a heavy user of the platform, you may need to purchase add-on capacity.

The part about how much API quota you get with each user license was neatly documented in MS Docs by the time October came around. That wasn’t really the problem. Can you guess what was the one thing that nobody knew, given that earlier there had not been any such API restrictions in place? That’s right: the actual rate of capacity consumption!

“You can’t manage what you can’t measure.” That’s what I wrote in my blog 5 years ago, in another post covering Power Platform’s shift towards licensing by consumption. It’s another lengthy read for those who want to revisit the pre Oct 2019 days:

As it turns out, Microsoft had only done the Excel exercise of looking at the internal Azure bill that the BizApps product group get each month. They must have divided the compute transactions with the number of tenants and licensed seats for Power/Dynamics customers, then figured out a threshold where 95% of customers are unaffected. The remaining outliers who had “heavy usage scenarios” would need to buy add-on capacity, so that no one gets a free ride with running massive API intensive workloads on the platform.

Sounds fair? In theory, it is a fair model. In practice, this is the ultimate example of FUD that you can inflict upon your own customer base. Because no one knew how the theoretical numbers would translate into practical limits, the most loyal customers and the most knowledgeable developers will end up worrying about it the most. You thus can’t target the practical change to those pesky outliers who might have unintentionally been abusing the platform. They won’t understand it anyway (or even know about it). With a message like this, you only hurt the ones that love you the most.

When I was still a Microsoft MVP, I witnessed loads of passionate individuals working with Power Platform try and get answers from MS on what the exact formula for calculating API capacity consumption was. While most understood Microsoft’s underlying intent to create reasonable guardrails for platform resource consumption, the issues were plain and obvious from day one to these community experts. Unfortunately, decisions related to the commercial model were mostly out of scope for any discussions that MVPs had with the product team.

(Strangely enough, what MS considered “product group interactions” (PGI) in the MVP program were actually “engineering team interactions”. In my opinion, if you exclude the commercial aspect of software licensing, you are not talking about product at all. Unless your product is free, of course.)

Let’s keep in mind that all the Dynamics based CRM implementations were lumped under the same Power Platform Requests mechanism as the citizen developer apps and automations with these new October 2019 rules. While a citizen might well end up creating a runaway cloud flow that should get throttled, enterprise CRM systems development includes high peak workloads like data migration, totally by design. Similarly, the more a customer has invested in integrating their Dynamics 365 system with signals and data coming from other LoB apps and customer interaction points, the more likely they will exhibit signs of heavy usage from API call perspective. Customers and consultants working with these systems had a lot of questions about the new licensing model practicalities - and almost zero answers.

Why were these limits so crucial for Microsoft? Many stories have been told by MS representatives about peak capacity consumption scenarios that lead to the need for capacity limits. Often the customer in question only had a handful of user seats licensed, yet they were running either massive bulk import/export processes, or leveraging Power Platform as the back-end for an online casino or something crazy like that. In a way, I sympathize with the challenge of how to deal with such customers when you are providing a global cloud SaaS for building apps and automations. You do need to have contractual rules written down somewhere, so you can address those outliers. But you can’t just solve that specific outlier problem while not analyzing the impact on the best customers in your user base.

Why is it then so hard for Microsoft to come up with the necessary reporting on actual consumption? Why, in 2024, is there still no estimate on when the Power Platform requests reporting will be GA?

I bet one of the trickiest parts has been in identifying what capacity consumption actually comes from the customer. I don’t mean identifying the target tenant or environment. I’m talking about excluding the platform usage that is caused by the platform itself. Because features and entire products within the MS portfolio are built from Dataverse solutions and integrated Azure services, they consume API calls just like customer specific apps would. The deeper you go into the analysis of what API call is triggered by a MS service and what can be classified as the customer’s platform usage - the harder it is to see any rays of light as you descend into the rabbit hole of Power Platform requests.

I recently wrote about the scarce resource of Dataverse storage capacity. A notable pain point on the storage side of platform usage has been the ever-increasing storage space consumed by Microsoft’s first-party solutions. What’s different here compared to Power Platform Requests is that the customers have already been paying for this for many years. As a result, they keep an eye on the metrics provided and understandably are not happy when actions from the SaaS vendor cause a higher add-on storage bill for them to pay.

Storage capacity has suffered from a similar administration issue as the Per App licenses. It has been hard or impossible to ensure that what you’ve bought is used for the intended purposes, as the storage capacity is managed only at tenant level, not environments. In a larger tenant with not so large quota of available storage capacity, the risks from someone building a runaway Dataflow that ends up eating tens or hundreds of GBs worth of database storage are too damn high. Luckily in 2024 we have finally started to get some capacity allocation tools built into the platform. Better late than never.

Storage capacity is the part we can measure fairly accurately, so it’s not the biggest FUD generator in MS BizApps licensing. That title clearly belongs to Power Platform Requests. It has been the most effective way to stop important business applications from being built as low-code solutions in recent years.

We need to talk more about licensing

I recently came across a great post from an ex-MS employee. He told one lesson that really stuck with him, after starting in the corporation as a young and eager IT professional many years ago, was this: "don't ever talk about license prices". It sounded like one of the rules from Fight Club, so I started thinking what would be the way for such people to find an escape from the pressures, frustrations and limitations set out by everyday corporate reality. Introducing the (fictional) concept of Microsoft Licensing Club:

The point of both this newsletter article as well as the various licensing related memes I share on social media is this: Microsoft licensing is important, but you shouldn’t take it too seriously. When people are scared to talk about a topic, you end up in the land of FUD as seen from the above-mentioned examples in Power Platform licensing model changes. Individual employees working for Microsoft may not be able to do much about the policies that are blocking them from licensing related discussions. Yet someone, somewhere, has invented and implemented such policies for that organization. As for us outsiders, we have the right to demand more clarity on these most crucial commercial parameters from our cloud service providers.

I’ve written a lot about MS licensing, since there have been so many unanswered questions related to it. I’ve approached it as an interesting challenge that has required practicing my logical thinking skills, especially given how not all parts of the information published from MS are necessarily logical. Through the mental exercise of writing about the topic, I’ve managed to fill in some blanks and provide answers to many fellow community members on how the licensing rules relate to real-world business application usage scenarios. Because while MS thinks in products and SKUs, the customers need a solution architecture that isn’t restricted to the items listed on a simple price list but is rather a combination of several components, often licensed separately.

When it comes to technical features of MS products, there’s a wealth of learning resources available today. Approaching these cloud tools and getting hands-on experience via self-paced labs is easier than ever. Awesome! And how are we doing on the commercial business case and licensing planning front? [*complete silence*]

We shouldn’t expect any normal people to be excited about opening the Power Platform and Dynamics 365 licensing guide PDFs. Not only does it feel too much like browsing through a terms and conditions style of legal text. The material often doesn’t address the everyday scenarios that customer environments consist of, as the MS documents are so product centric. In reality, every Power Platform deployment is a combination of various products and services being applied to solve problems that rarely have an exact match in the feature set of any single MS tool. Explaining the expected costs and license types needed should really be done via such scenarios picked from the real world. Whether Microsoft themselves could ever get the communication down to that level - I’m not sure.

This is where the independent players in the ecosystem could of course be of assistance. Recently I came across a new certification product launched by the awesome Licensing School - a company focused on explaining how Microsoft licensing really works. Their Microsoft Licensing Body of Knowledge 2024 Power Platform exam is a paid exam, but LS also published a set of mini exams that are free for anyone to take. 10 questions on Power Apps, Power Automate, Power Pages, AI Builder, Power BI - OH YES! Who could resist trying out those exams and seeing how fast they can speedrun through them? Not me!🤓

Often it is the people who are truly passionate about what they do who can explain complex topics in an approachable way. Similarly, you often need a certain degree of liberty to say how you really see things - not just repeating the formally approved corporate message. I’ve found this combination to help organizations deal with the feelings of fear and doubt often associated with MS licensing challenges. We may not always be able to eliminate uncertainty, but at least we can (re)build confidence towards Power Platform as a solid foundation for business apps, both technically and financially.

This is the kind of advisory work that I find both valuable and rewarding. If you ever run into situations where such help would be needed, don’t hesitate to reach out to me at Niiranen Advisory. I’ve now made a Calendly page for myself to streamline the experience of setting up either a paid advisory session or an intro call. You’ll find my availability at meet.niiranenadvisory.com .