Power Platform | Licensing revisited

Beginning of last year, I started a blog series called Licensing Tetris outlining a couple of ideas, thoughts and best-practices around Power Platform licensing. This year, I thought of revisiting this topic due to changes introduced by Microsoft to the licensing over the course of last year and also based on even more interaction with customer procurement- or license management teams. Not to forget consultants and sellers being involved in this process. One thing that hasn´t changed on my side:

Licensing should not be your architect when starting discovering a solution to a problem statement

Carsten Groth

Let me outline this in more detail with the following visual that I created when customer´s license management teams where asking me on recommendations for internal billing Power Platform services to departments using any services out of this bucket.

Above visual shows the structure of each entitlement coming with typical Power Platform licensing options. Yes, I dropped the Dynamics 365 seeded one for simplification – great catch by the way. My source creating this and additional visuals was Microsoft´s licensing guide as of December 2021 for Power Platform. As you can see each license type comes with one or more entitlements offered additionally. Those could become quite important for an organization, but more on this later. The license part itself being significantly low compared to those entitlements, suprisingly being seen and referenced only by many teams, such as procurement or license management during negotition.

Because of that, I´ve created above visual which is a fictive situation for a company with 35.000 users in total using at least one of both standard- and premium-tiered apps. Additionally, you can see that I´ve used Power Apps licensing only in this visual. This is due to:

• The more additional products you use within Power Platform, the more you need to look into bundling licensing options, create packages and apply each of those licensing details
• Power Apps is often times seen as a starter to begin with the low-code/no-code digital transformation journey
• There simply is no all-over Power Platform licensing

To the right of this visual, I am sharing some perspectives collected from the work with procurement- and license management teams as we started to discuss how an internal billing process could look like.

The first, acknowledge that any user-based licensing model takes more time, effort and up-front work in terms of usage modeling. And this being a reason of customers considering to begin with PAYGO first instead, as it allows for an immediate start and ramp-up and later making decisions to go up-front commitment. You can see from the visual above that the curve though – due to being metered by monthly active usage (MAU) – may go up and down and budgets therefore varying on a monthly base and of course based on the amount of users consuming (running) an app.

Departments and companies might struggle with that if budgets are not calculated on a flexible manner and a monthly base. You could imagine a single HR department based on usage being billed 10k in one month, 15k then the following month and dropping to 8k in the next might struggle. Azure customers though would already be familiar with this, but many times use the Azure Cost estimator to up-front calculate expected usage – not to be suprised afterwards with a significantly higher bill than planned. Them creating Azure budgets and Azure groups to manage all this – something, I´d recommend every PAYGO Power Apps starter to do so as well. Find more on this topic here.

In a per App scenario this being outlined typically as a stairway which is seen at many customers starting with one application, then adding more over the course of time, keeping the per App licensing for each of them. Additionally, taken into account that if apps being deployed through more than one environment it might take a single user being required of 2 or more licenses of it, due to running this app in each of those environments. Something to consider, when talking about apps that are taken in an Application Lifecycle Management (typical 3-layers of environments).

Both in O365 and per User licensing option it shows a little different. More or less a constant line unless the amount of users would change. The amount of apps consumed being out of consideration as both allows for an unlimited scenario – more on this later shown in a matrix.

This also outlines the up-front work that would need to be taken care of – An estimation of the amount of users you would like to equip with this capability. Suprisingly, customers feel enabled to do this for the Office suite, but struggle when it comes to Power Apps. Why is this?

When talking to procurement teams, many times they operate on a mandate by requesting departmental needs, collect and use it before negotiating new license contracts. So is someone at procurement asking for – How many users in your department will use Excel? Or, how many users in your department will use Word? Well, I don´t think so and got proofed right – as many times the pattern would be not to look into the details of the suite, instead simply take into account if a user might use it or not.

Well, why isn´t it the same pattern for Power Platform then? Why not simply asking: How many users you (department) would like to equip with capabilities of Power Platform? Instead, what I´ve seen many times happening is them (procurement) asking for help of IT department. Them then starting activities like – give me use-cases that you´d like to use Power Apps for. And the departments fail to answer it, because of them not knowing what Power Apps is capable of. A typcal chicken and egg problem statement. Those times I ask myself if there was ever a time when IT departments where asking departments of how many users of Excel, Word or PowerPoint would be needed? Send me answers via comments or email.

Above visual compares the current Power Apps licensing and breaks each option down into capabilities. You see a lot of references (blue) in there. As all of them together with above metrix doesn´t fit on a single slide (unless it becomes unreadable), please find them here:

The reason of bringing both visuals up at this time is shifting gears and focus to the additional, often times ignored parts in finding the right licensing option after discovery of the problem statement. Another reason of this is, knowing that we sometimes like to be lazy and take the easiest option. In this case being either to go with O365 licensing only or going with PAYGO.

Last option enables for a quick start, avoids up-front usage modeling, but nevertheless takes effort in setup when taking into account the internal billing. Microsoft recently shared this via a Community meeting:

Outlining common scenarios for PAYGO and highlighting it for an easy way to split costs for Power Platform licensing / usage across different departments. While not disagree to this, I´d like to add that it takes effort and quite an understanding of the environment strategy that would be needed to enable this scenario.

• because of the PAYGO Azure subscription being assigned to an environment
• each Azure subscription- or PAYGO enabled environment can be mixed only with additional per User licensing
• the default environment coming with O365 tenant may not be the best environment assigned an Azure subscription to it as a best-practices

In other words, what might look like a simple to implement and start with option, could be the same amount of effort drilling into the usage modeling – depending on how complex you structure this process. Requesting and hunting for use-cases, like asking each department on how many of them would use either Excel or Word or simply hunting for enabling a certain amount of users inside each of these departments first and adjust afterwards (which is more or less what happens on the O365 side).

As I outlined before, there´s no single Power Platform license. I therefore may or may not stretch this out in a series again that covers the other components. Let me know if you´re interested in this. Until then,…