Per app, per user, and capacity: the fastest growing sprawl problem in most Microsoft estates. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. Once in the session the frame splits and a senior cloud advisor gives the view from inside real Oracle negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back, session twenty four of forty. Last session was Dynamics, where the problem was mapping people to rungs on a ladder. Today is Power Platform, and the problem is different in a way that matters. On this platform, the people generating cost are not buying anything. A maker adds a connector to solve a problem. A flow writes data on a schedule. An app spreads from one team to five. None of that passes through a purchase order, an approval, or a conversation with procurement, and all of it changes what you owe. That is why the headline finding across the reviews behind this session is that sprawl rather than unit price drives most of the overspend. Which means the work here is not negotiation and it is not even really licence selection. It is making the cost of a design choice visible at the moment somebody makes it.
Five takeaways. One, six families rather than one product: Power Apps, Power Automate, Power BI, Power Pages, Copilot Studio, and Dataverse, each licensed independently, and customers commonly buy three to five together. Two, the plan choice: per app for long tail makers, per user for heavy makers, pay as you go for sporadic apps, and mismatch left licences stranded on both sides. Three, the connector trap: a single premium connector can pull a maker into a higher band, and premium connector use pulled twenty to forty percent of makers into a band their app did not justify. Four, the capacity surprise: Dataverse capacity bills separately and overage produced unplanned true up charges in most estates reviewed. Five, the real lever: governance beats licence shopping, because sprawl rather than unit price drives most overspend, which makes this a control problem before it is a purchasing one.
Six families, one platform, and three things that create the complexity. Each family licenses independently: Power Apps, Power Automate, Power BI, Power Pages, Copilot Studio, and Dataverse each have their own SKU structure, their own metering, and their own renewal characteristics, so there is no single Power Platform licence to reason about, which is the first thing to correct in internal conversation. The interactions are the cost: Power Apps consuming premium connectors create per app licence requirements, Power Automate flows moving data into Dataverse consume capacity, and Power BI dashboards embedding Power Apps objects need capacity as well as the app licence. And the interactions are not fully documented, because those cross family effects are not always set out in the licensing guide, which means the way to discover them is to model your own estate rather than to read your way to certainty. That last point is unusual and worth accepting early.
The plan choice, three shapes and what each is for. Per app: long tail makers running one or two apps, at around five dollars per user per app per month, and the thing to watch is counting apps as they multiply, because around the third app the maths inverts. Per user: heavy makers working across many apps, where the risk is paying for rights never used on a light population. Pay as you go: sporadic or seasonal apps, with unbudgeted metered spikes as the trade, and everything from session seventeen applying. Dataverse capacity: which affects every estate whether or not anybody planned for it, and the watch item is overage at the true up, which hit most estates reviewed. And premium connectors, which are not a plan at all, they are a trigger, because one connector can move a maker into a higher band. Per app against per user is a crossover calculation exactly like the edition crossover in session twenty two, and the mismatch was found in both directions.
First check. A department has sixty makers, most running one app each, and four running eight apps apiece. What is the licence shape? A, per user plans for all sixty four, for simplicity. B, per app for the long tail and per user for the four heavy makers, because the crossover runs the other way for each group and one policy strands licences on both sides. C, per app for all sixty four. D, pay as you go for everyone. Pause it. Two populations with opposite profiles, so ask yourself what a single policy would cost each of them separately.
The answer is B, and by session twenty four this shape should be recognisable: two populations with opposite profiles, and a single policy that is wrong for one of them whichever way you choose. A buys unlimited app rights for sixty people running one app each. C stacks per app licences on four people running eight apps apiece, which inverts the arithmetic somewhere around the third app. Plan mismatch left licences stranded on both sides in the estates reviewed, and it is usually a mismatch in both directions inside the same organisation, because the plan got chosen once and the population changed afterwards, which is the recurring mechanism across this entire module. D is genuinely useful for sporadic or seasonal apps and it is not a default, because unbudgeted metered spikes are the trade you accept for that flexibility. Run the crossover, draw the boundary, and re run it annually as makers grow, because they do grow.
The premium connector trap, five things about the connector that changes the band. One connector is enough: a single premium connector in a single app can pull the maker, and the users of that app, into a higher licence band, and it is a threshold rather than a gradient. It happened to twenty to forty percent of makers across the reviews behind this session, pulled into a higher band than their app justified. Nobody experiences it as a purchase: a maker picks a connector from a list to solve a problem, there is no price beside it in that moment and no approval step, which is exactly the agent problem from session eighteen in a different setting. The alternative often exists, because many premium connector uses have a standard connector route that is slightly less convenient and does not change the band, and that trade is invisible unless somebody surfaces it. And it is discoverable centrally, from the admin centre, monthly, and almost nobody runs that report.
Guest analyst The Power Platform conversation I use as a teaching example involved an app that did something completely mundane. A utilities company, and somebody in field operations had built a small app for logging site visits. It was good. It spread, the way good internal apps do, from one region to about eleven hundred users over roughly a year, and nobody minded because it was solving a real problem cheaply. Then a maker added a premium connector so the app could write into another system, which removed a manual re keying step and was, on its own terms, an excellent decision. What nobody in that chain knew was that the connector changed the licensing band for everybody using the app. Not for the maker. For all eleven hundred. And there was no moment where anybody was told. The app kept working, the users kept working, and the consequence appeared at the true up about eight months later as a number that took the licensing team two weeks to trace back to its cause. Now, the reason I use this example rather than a bigger one is what happened after. They did not ban premium connectors, which would have been the obvious reaction and the wrong one, because the connector was genuinely the right engineering choice. They set up a monthly report from the admin centre showing which apps used premium connectors and how many users each of those apps had, and they added one rule: an app crossing a user threshold gets a licensing check before it goes wide. That is it. Two hours of setup, and it turned an annual surprise into a monthly decision.
Eleven hundred users moved band by one good engineering decision, discovered eight months later. One report, one rule. Second check.
Check two. A maker adds a premium connector to a widely used app. What changes? A, nothing until the next renewal. B, the licence requirement for that app changes immediately, and everyone using it may need a higher band, which is a cost created by a design choice rather than a purchase. C, only the maker's own licence is affected. D, nothing, connectors are included in all plans. Pause it, and as you think, ask how many people use that app, because the answer to this question scales directly with them.
The answer is B. C is the intuition that makes this so expensive, because it feels like a maker's decision affecting a maker's licence, when the requirement actually attaches to the app and therefore to its entire user population. One person's design choice on a Tuesday afternoon can change the licence band for several hundred people, and nothing in the experience signals that at any point, which is exactly the story you just heard. A confuses when you get billed with when the requirement arises: the entitlement changes immediately and the invoice catches up at the true up, and that lag is where the surprise comes from. D is simply incorrect, and it is a common belief because the connector list does not distinguish premium from standard in a way that anybody notices while they are building something. The control is a monthly premium connector report and a rule that widely used apps get a licence check before a premium connector goes into production.
Capacity, and the true up surprise, three things about the layer underneath. It bills separately from seats: database, file, and log capacity are their own lines, and a per user or per app licence does not carry unlimited storage with it, while the entitlement that comes bundled is smaller than most estates assume when they start building. Flows consume it silently: Power Automate flows moving data into Dataverse consume capacity as they run, and a flow written once consumes forever on a schedule, which is precisely the agent arithmetic from session eighteen in another guise. And overage arrives at the true up, having produced unplanned charges in most of the estates reviewed, which makes it one of the most reliably surprising lines in the whole Microsoft estate, because nothing about the daily experience suggests a meter is running anywhere. Treat capacity the way session seventeen treats credits: a metered line inside a per user product, reviewed monthly, with a named owner and an alert.
Governance beats licence shopping, five controls in order of what they return. Premium connector report: catches apps that moved band without a decision, monthly, minutes, straight from the admin centre. Capacity trend: catches storage and log growth before the true up, monthly, one chart. Maker inventory: who is building what and how many apps each, quarterly, and it feeds the per app against per user crossover. Orphaned apps: apps whose maker has left or moved on, quarterly, and consistently the easiest reclaim on the platform. And environment strategy: uncontrolled sprawl across environments, annual, and much the hardest of the five to retrofit, which is why it is last. Sprawl rather than unit price drives most overspend on this platform, which means the licensing answer here is a governance answer. Four of those five are reports somebody runs, and none of them require a negotiation, a new tool, or anybody's approval.
Last check. Power Platform spend is up sixty percent and nobody bought anything. What happened? A, a pricing increase must have been applied. B, sprawl: more apps, premium connectors moving bands, and capacity accruing from flows, none of which involved a purchase decision. C, somebody bought licences without authorisation. D, the estate grew by sixty percent. Pause it. And notice the framing of the question, because on this platform every cost driver can be triggered by somebody who is not buying anything at all.
The answer is B, and this is the defining characteristic of Power Platform as a commercial object: the people generating cost are makers rather than buyers, and none of the three main drivers passes through a purchasing decision. More apps means more per app licences or more people pushed toward per user plans. Premium connectors move bands. Flows consume Dataverse capacity on a schedule, forever. A checks the simplest explanation, which is worth ruling out and rarely accounts for a movement of this size. C looks for a culprit where the process is the problem, and it damages your relationship with exactly the makers whose cooperation the fix depends on, so it is worth resisting even when somebody senior suggests it. D would explain it and is usually not what happened, because platform spend routinely grows several times faster than headcount. The response is the control set, starting with the premium connector report, and the tone matters: governance gap, not misconduct.
The platform method, three steps, and none of them are a negotiation. One, inventory the makers and apps: who builds, what they built, how many apps each, and how many people use each app. That single table drives the plan crossover, the connector risk, and the orphaned app reclaim all at once, which makes it unusually good value for the effort. Two, surface the licensing consequence: a rule that any app going to a wide audience gets a licence check, plus a monthly premium connector report so band changes become visible when they happen rather than at the true up eight months later. Three, meter the capacity: a monthly capacity trend with a named owner and an alert, exactly as with credits in session seventeen. And do all of this with the makers rather than to them, because that community is usually delivering real value quickly, and the goal is visibility at the moment of choosing rather than slowing the building down.
Session twenty four, three sentences. One: Power Platform is six independently licensed families sharing a runtime and a data layer, and most of the complexity comes from interactions between them that are not fully documented, so you model your own estate rather than reading your way to certainty. Two: plan fit is a crossover calculation in both directions, and a single premium connector can move a maker and everyone using their app into a higher band, which happened to twenty to forty percent of makers. Three: sprawl rather than unit price drives most overspend, so the controls are a premium connector report, a capacity trend, and a maker inventory, none of which are negotiations and all of which are monthly or quarterly reports. Next session closes module five with security and identity, and the overlap question we first met back in session thirteen.
Homework, about an hour, and this week you run two reports. One, pull the premium connector list: which apps use premium connectors, and how many people use each of those apps, because that is the report that most directly explains your bill. Two, chart capacity: Dataverse database, file, and log capacity over the last twelve months against your entitlement, one chart, and the trend is the finding rather than the current number. Three, count apps per maker, and look at the distribution rather than the average, because you are hunting for the long tail and the heavy few who need different plans. Four, find the orphans: apps whose maker has left or changed role, and apps with no users in ninety days, which is the easiest reclaim on the platform. Five, write one rule: any app going to more than a set number of users gets a licence check before release, one sentence, agreed with the platform owner.
Five reads before next session, all free on redress compliance dot com. First, the CIO playbook for Power Platform licensing strategy, which carries the six families, the plan fit, connectors, and capacity in full detail. Second, the Dynamics 365 licensing guide, because it is the neighbouring family and shares the Dataverse layer underneath, so capacity problems there and here are the same problem. Third, auditing your Microsoft licence usage, on how to produce the inventory this whole session depends on. Fourth, the Microsoft licensing guide, for where the platform sits inside the wider agreement. And fifth, common Microsoft licensing mistakes, several of which turn out to be sprawl rather than purchasing errors, which is the theme of today. Next session closes module five: security and identity. Entra tiers, Defender, and Purview, what is bundled in E5, what is sold separately, and the overlap with tools you already own. See you there.