The metric families, the base and attach structure, and the sprawl that shows up at renewal. 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 three of forty. Last session was the server estate, which is a counting problem. Today is Dynamics 365, which is a mapping problem, and a rather different kind of work. Here is the thing to hold onto from the start. Dynamics is not one product with one price. It is a family of applications, each licensed per named user, and underneath them sits a ladder with a very wide gap between the rungs. Full base licence at the top, a much cheaper attach licence for a second application on the same person, and Team Members at the bottom for light participation. Almost every commercial problem in this product family reduces to one question: is each person on the right rung. And the reason that question goes unanswered is not difficulty, it is that Dynamics usually sits with a business applications team while the bill sits with procurement, and nobody owns the join.
Five takeaways. One, the model: licensed per named user, per application, per month, where the first qualifying application is a base licence and the second is a much cheaper attach. Two, the ladder: full base, attach, and Team Members, and Team Members is cheap precisely because its use rights are deliberately narrow, which is where the compliance risk lives. Three, the overpayment: between twenty and thirty percent of full base seats were doing work that an attach or a Team Members licence covered. Four, the exposure: roughly one estate in three had Team Members assigned beyond its published use rights, which is a quiet compliance problem rather than a cost problem. Five, the add ons: Copilot, Premium tiers, and capacity all bill on top of the base application, and add ons were assigned org wide in about forty percent of cases with real use under half the assigned seats.
How it is actually licensed, three structural facts. A family rather than a product: Dynamics 365 is a set of applications, each licensed per named user per application per month, and talking about a Dynamics licence in the singular is the first step toward a quote nobody can check. That happens constantly in internal conversation and it is worth correcting whenever you hear it. Base and attach: the first full price application a user holds is the base licence, and any additional qualifying application that same user needs is an attach at a much lower monthly rate, provided the first one qualifies as a base. And the Product Terms govern: use rights come from the Microsoft Product Terms rather than from a sales summary, a deck, or a helpful email, and that distinction matters most on Team Members where the boundary is narrower than people assume. The whole commercial question reduces to whether the licence each person holds matches the work each person does.
The licence ladder, three rungs and a wide gap between them. Full base licence: complete use rights for one application, for people whose primary job runs in that application. Attach licence: a second qualifying application on a user who already holds a base, for anyone genuinely working across two applications. Team Members: light, read mostly and basic write tasks across applications, for occasional participants, approvers, and readers. Then above the ladder sit Premium tiers and Copilot, priced on top, and only justified where measured use supports it, which is module four applied here. And beside the ladder sits capacity, storage, database, and add on capacity, which affects everyone invisibly until the true up. Team Members is cheap because its use rights are deliberately narrow, and that is the trade: it is the correct licence for a large population and the wrong licence the moment somebody uses it for work it does not cover.
First check. A user holds full base licences for two Dynamics applications. What is likely wrong? A, nothing, they need both applications. B, the second should almost certainly be an attach licence at a much lower rate, since attach exists precisely for a user who already holds a qualifying base. C, they should be downgraded to Team Members. D, two base licences on one user is a compliance breach. Pause it. Notice as you think that the need for both applications is not in question here. The price paid for the second one is.
The answer is B. Nothing about the requirement is wrong, which is exactly what makes this pattern so persistent: the user genuinely needs both applications and the licensing genuinely covers them. It just costs considerably more than it needs to. Attach pricing exists for this precise case, and it gets applied by whoever assembles the order rather than discovered by the user, so nobody in the business ever notices, because from the user's side everything works. D is worth correcting directly because it does come up: holding two base licences is not a breach, it is an expensive way of being compliant, and confusing overpayment with exposure sends the whole analysis off in the wrong direction. C is the opposite overreach, moving somebody with genuine two application needs onto a licence built for light participation, which would create the very compliance problem D imagined. Check every multi application user for attach eligibility. One query, often the largest single line in a Dynamics saving.
Where estates overpay, five patterns from the benchmarked estates. Full seats doing attach work: between twenty and thirty percent of full base seats were doing work an attach or Team Members licence covered, and that is the headline number of this session. Team Members stretched too far: roughly one estate in three had it assigned beyond its published use rights, which is exposure rather than saving, and it usually arrived through helpfulness rather than intent, an administrator giving somebody access to get a job done. Add ons assigned org wide: Copilot and Premium across the organisation in about forty percent of cases, with real use under half the assigned seats. Leavers still holding licences, because named user licensing means an unreclaimed seat bills indefinitely, and the joiners process is always built while the leavers process frequently is not. And capacity nobody watches, accruing quietly and appearing at the true up. Note the first two pull in opposite directions and an estate can easily have both.
Guest analyst The Dynamics review I think about was a distribution business, about nineteen hundred licensed users, and the reason they called us was that the renewal had come in higher than expected and nobody could explain why. So we asked for two things. The licence assignment list, which took an afternoon, and a transaction profile per user, which took about three weeks because it had to be pulled application by application. And that three weeks is the whole story really, because the answer was sitting in data they already owned. What came back was that roughly a quarter of their full base seats had, over the previous six months, only ever read records, approved something, or updated a single field. That is Team Members work. Not close to Team Members work, squarely inside it. And separately, about a hundred and forty people held two full base licences where the second one qualified for attach, which nobody had ever applied because the original order had been assembled department by department as the rollout progressed. Now here is the part I want to be fair about. The business applications team had not done anything wrong. They had provisioned what people asked for, promptly, which is what a good internal team does. Nobody had ever given them a rule that said check the ladder first, and nobody in procurement had ever seen a transaction profile, because those two groups had not been in a room together since the implementation. The re map was worth about thirty percent of the annual Dynamics bill, and every single input to it had existed all along.
A quarter of full seats doing read and approve work, and the data had been there the whole time. Second check.
Check two. An administrator assigned Team Members to two hundred warehouse staff who now enter goods receipts. Is that safe? A, yes, Team Members allows basic write tasks. B, check the Product Terms against the specific transactions, because Team Members use rights are deliberately narrow and one estate in three had it assigned beyond them. C, no, warehouse staff always need full licences. D, yes, provided they use it for under an hour a day. Pause it. And notice that the question is not how much they use it. It is which specific rights the work requires.
The answer is B. A is the reasoning that produced the finding in one estate out of three. Team Members does allow some basic write activity, and the boundary is set by which specific scenarios are permitted rather than by any general sense of lightness, so the only way to answer this is to read the actual entitlement against the actual transactions those two hundred people perform. D is the most common misconception in this whole area and I want to name it clearly: there is no time based threshold anywhere in this. Occasional use of a right you do not hold is still use of a right you do not hold, and an hour a day is not a defence. C is the overcorrection that costs real money, because a genuine light participant population is exactly what Team Members exists for, and defaulting all of them to full licences discards the saving the ladder is designed to deliver. Read the terms, list the transactions, and put the mapping somewhere the administrator assigning licences can actually see it.
What bills on top, three layers above the application licence. Copilot: priced on top of the base application, and everything from module four applies unchanged, so measure active use, license by persona, expand on evidence. Add ons were assigned org wide in about forty percent of cases with real use under half the assigned seats, which should sound extremely familiar by now. Premium tiers: enhanced versions of an application sold as an uplift, and the test is the same as the E3 to E5 test from session twelve, which is which specific capabilities are being used, by whom, and what would be switched off if you bought it. And capacity: storage, database, and add on capacity, accruing quietly with usage and surfacing at the true up. That is a consumption line living inside a per user product, and it needs the monthly review habit from session seventeen rather than an annual surprise. The pattern across all three is one you have now seen four times.
The sprawl at renewal, what to reconcile before the conversation, and there are five checks. Base against attach: users holding two full base licences, where the typical finding is that attach eligibility was never applied to multi application users. Full against Team Members: full seats doing light participation work, where twenty to thirty percent of full base seats sit too high. The Team Members boundary: rights used against rights held, where one estate in three assigned beyond the published rights. Add on assignment: assigned seats against active use, org wide in forty percent of cases with use under half. And leavers: named users who have left or changed role, with seats billing and nobody attached to them. Five queries, all five running against data you already hold. The reason this rarely happens is not difficulty, it is ownership, and the reconciliation belongs to whoever is willing to ask both teams for their list.
Last check. Your Dynamics renewal quote assumes flat seat counts. Your usage data says twenty six percent of full seats do attach level work. What do you table? A, the flat renewal, seat counts are hard to change. B, a re mapped licence mix built from the transaction evidence, priced beside the flat quote, because that reduction changes what you buy and therefore survives the discount conversation. C, a demand for a deeper discount on the flat quote. D, a move to CSP to get better pricing. Pause it. This is the session eleven mix argument arriving in a different product family, so the answer should feel familiar.
The answer is B, and it works for the same reason it worked in session eleven: a change to what you buy survives the discount conversation, because it is not a concession anybody can trade back later. Twenty six percent of full seats sitting a rung too high, on a ladder with a wide gap between rungs, is a larger number than any discount you will negotiate on the flat quote. C accepts the seat count and argues about the rate, which is the session ten error in yet another costume. A treats the mix as fixed, and named user licensing is actually one of the easier things to change at a renewal boundary precisely because it is per user rather than per device or per core. D is a genuine option worth evaluating on its own merits, and it is a vehicle question rather than an answer to this one, because moving the wrong licence mix to a different purchasing channel simply buys the wrong mix somewhere else, at a slightly different price.
The Dynamics method, three steps, and if you built the persona model in session fifteen then most of this is an extension of work you already have. One, list the transactions: per user, what they actually do in each application, create, edit, approve, or read. That transaction list is what maps a person to a rung and it is the only defensible basis for a Team Members assignment. Two, map to the ladder: every user to exactly one rung per application, with attach applied wherever somebody holds a qualifying base, and name the exceptions rather than leaving a residue, exactly as in the licence mix model. Three, reconcile the add ons: Copilot, Premium, and capacity against measured use, which is module four's method applied to a different product, and the forty percent org wide assignment figure tells you roughly where it will land. Give this the same fortnight you gave the Microsoft 365 mix model and expect a similar shape of answer.
Session twenty three, three sentences. One: Dynamics 365 is a family of applications licensed per named user per application, where the first is a base licence and any additional qualifying application is a much cheaper attach, so two full bases on one user is a pricing error rather than a requirements error. Two: between twenty and thirty percent of full base seats were doing work an attach or Team Members licence covered, while one estate in three had Team Members assigned beyond its published use rights, and both come from the same absence of a transaction level mapping. Three: Copilot, Premium, and capacity all bill on top, assigned org wide in about forty percent of cases with real use under half, and capacity behaves like a consumption line needing a monthly review rather than an annual surprise. Next session is the platform underneath a lot of this, where sprawl rather than unit price drives the overspend.
Homework, about an hour, and this week you audit the ladder. One, find the double bases: users holding two or more full base licences, and check each for attach eligibility, because that query alone often pays for the hour several times over. Two, pull the transaction profile: for one application, what each user actually does, create, edit, approve, or read only. Three, test the Team Members population: read the published use rights, compare them against those transactions, and note anything sitting outside the boundary. Four, check add on use: Copilot and Premium assigned seats against active users, and expect a gap, then quantify it rather than describing it. Five, run the leavers query: named licences held by people who have left or changed role, reclaim them, and then find out why nobody already had, because that answer is the process fix.
Five reads before next session, all free on redress compliance dot com. First, the Dynamics 365 licensing guide, which carries the model, the per user maths, and where buyers overpay. Second, common Dynamics 365 licensing mistakes, which is the patterns from this session with the detail behind them. Third, the CIO playbook on negotiating Dynamics 365 contracts, for taking a re mapped mix into the commercial conversation. Fourth, Dynamics 365 in enterprise agreements against CSP, which is the vehicle question and is genuinely separate from the mix question, though the two get conflated regularly. And fifth, the Dynamics 365 renewals playbook, which sets out the renewal reconciliation in the order to run it. Next session is Power Platform: per app, per user, and capacity, and the premium connector that quietly moves a maker into a higher band. See you there.