What I Like About the New Power Platform Pay-As-You-Go Meters

One of the big announcements for me at Ignite was the ability to link Power Platform to Azure for managing consumption and charges.

The announcement covered three areas (App Usage, Storage, and Requests). Here is what I think it means for the Power Platform.

For the quick version of what was announced, here is a summary below, care of Microsoft docs.

Pay as you Use: The Per App Meter

The Per App meter adds a third column to our usual Power App pricing.

Clearly the new Plan is designed for infrequently used applications but it also goes some way towards solving a problem that has plagued Dynamics since v4. Specifically, the problems of internal use.

An obvious use for Dynamics 365 Customer Service is for internal support e.g. IT helpdesk. The problem is Microsoft has always been hard-nosed about licensing internal users. In short, if an employee or someone whose actions are “guided” by the organisation e.g. a contractor, access Dynamics, regardless of the interface, they need a user license. While there are concessions about accessing Cases of one’s own creation with Power App, Power Automate, and PVA licensing (check disclaimer (1) here for details), until this new Plan came along, effectively every user needed to be licensed for the App, whether they used it or not.

For small organisations, this was not such a big deal but for larger organisations, it was always a deal-breaker, sending prospects to competitors such as ServiceNow who do not charge for “Requesters”. Microsoft used to offer heavily discounted licensing for direct ServiceNow compete scenarios but I have not seen this being offered for a long time.

With the new model, Microsoft partners no longer have to walk away from internal support opportunities. Let us say an organisation has 20,000 employees. Rather than pay US$5*20,000 on the off-chance an employee logs a ticket, they will pay based on request volume which, for larger organisations should be fairly predictable.

There are scenarios which still fall through the cracks e.g. a Personal Assistant logging a ticket for an executive needs, by the letter of Microsoft law, a full Dynamics 365 Customer Service license if the protected Case entity is being used. Also, a spike in tickets on the same subject could prove quite expensive.

To show how ridiculous the licensing model is, the workaround is to use emails. If an employee sends an email to a Dynamics queue this is not considered accessing the system. So, a theoretical workaround would be to get users to email support requests, rather than use a self-service portal. We might even be able to format the body of the email so it could be read by a Flow and capture structured data.

Another, less common scenario, which falls foul of Microsoft licensing, is where an infrequent specialist is required to resolve a Case. Where I came across this was at a large university which processed student enquiries. In some cases it was necessary to seek out an academic for advice. Academics, being simple folk, did not need to access the entire Dynamics 365 system. A simple App which listed the Cases for review and allowed them to pass on their thoughts was enough. However, as with the internal tickets, this meant literally every academic needed to be licensed in case they were called upon. Again, the new licensing model goes towards addressing this.

I have often wondered if the approval function of Power Automate triggers the need for a license given it can pass the requests via email. I have raised this a few times with different people at Microsoft with a wide spectrum of responses ranging from “you might be onto something” through to “nice try, Leon”.

For me, the takeaway is any licensing model which encourages workarounds (SharePoint mutiplexing anyone?) and hinders innovation is a broken licensing model which makes the vendor look confused and out of touch.

Pay as you Store: The Capacity Meter

Not too much to say on this one. I like the idea of the shared tenant capacity pool but, as Jukka points out, turning the meter on turns the pool off and replaces it with a baseline capacity (see picture further up) with charges for anything over this. Of the three meters I can see this one generating the most nasty surprises due to data imports or aggressive file attaching.

Pay as you Request: The API Meter

This is one I like the most and, this being the Thanksgiving weekend, we have an example to see why. Let us pretend my Etsy shop relies on Power Platform in some fashion and every sale I make generates calls to the Power Platform API. Through the year the usual entitlement is sufficient but let us say the Black Friday sales cause a run on pocket watch pill boxes and insulin pen cooling pouches (they also work great for epi-pens) and I exceed the request limit. What do I want to happen?

One option would be for Microsoft to throttle or turn off the pipe. Given the volume of sales, this is undesirable as it could lead to timeouts and lost sales. Linking to Azure means the excess calls get charged but, given the calls are directly associated to sales, I do not really care as I will be making money anyway.

Interestingly, at the time of the announcement of the public preview of this feature, those who turned it on were not going to get charged for excess calls for at least a few weeks. Perhaps Black Friday and Cyber Monday will be covered after all.

Last Thoughts

So there you have it, new ways to pay for Power Platform using Azure dollars which, if you have a monthly amount set aside, may well be a compelling option. In terms of starting to fix the infrequent internal user issue, it is a step in the right direction. Also, in terms of providing a clear answer to how Microsoft wants organisations to manage excess API calls, we now know where we stand.

For those of us who design solutions on the Power Platform, it adds slightly more complexity, as it requires us to know details of our clients’ Azure subscriptions which may or may not be accessible but, overall, I think it is a positive move.