Source-cited breakdowns, verified against official Microsoft documentation. No vendor spin.
Personalizations and saved views are bound to security roles. Redesign the roles without carrying them across and people lose their screens on day one. How to keep the change invisible.
Never revoke access until the replacement is proven in. Ship de-provisioning as a signed-off list first and an import file last, so a cost optimization never breaks someone's day.
Swap the ruleset and a segregation-of-duties conflict count moves from 870 to 353 without any security changing. Inherited rulesets are routinely contaminated. Fix the instrument first.
Restrictions are a second, inverted permission layer. An analysis that ignores read-only denies miscounts access, and a careless redesign can revoke access users needed, not just trim cost.
A user-role assignment with no organization rows grants access to every legal entity. Ship one unscoped assignment in a package and you widen access across the whole company by accident.
The System Administrator role carries zero rows in the privilege model most analyses are built on, so the most powerful accounts score as the cleanest. A blind spot worth naming.
Which D365 security grants you can observe from write-evidence is fixed by the platform: about 89% of screens, 22% of outputs, 7% of actions, 0% of in-form controls. A structural constant.
The belief that nothing can be done about a D365 license bill is the most expensive one in the room. Microsoft sets the price and the rules. How many licenses you actually need is a function of your own security configuration, and that is yours to change.
One service account posted 44.6 million rows. When batch and integration accounts dominate an audit trail, per-user signal disappears, and a naive read of the log misleads.
The actor behind D365's highest-stakes verbs, posting and approving, is usually not recorded. What that means for audit evidence, and why a license analysis has to account for it.
A redesign can hand tens of thousands of permissions to users who do not need them, and a dollar-based budget sees none of it, because access that costs nothing is invisible to cost.
A modeled saving of $171,552 looked real until you asked how much hits the next invoice. The answer was near zero until revocation ships. The one question to ask of any quote.
Restoring missing usage data raised the modeled cost from $1.83M to $2.21M. The honest number went up, not down. Why more evidence can make a design look worse, and why that is right.
A saving you cannot bank until the package actually ships it. On one estate the designed cost sat 61.5% below the shipped cost, and the shipped saving was zero.
Modeling a client's per-role license intent and the process change behind it: find the driver, re-route to a cheaper entry point or drop it, then confirm the tier actually fell.
'We don't run Commerce, take it off our bill' is surgery, not a toggle. The pros, the cons, the ties and service operations that trip it up, and governing intent so drift cannot undo it.
Some organizations want the leanest defensible design. Others want to change nothing that isn't costing them money. We built a dial for it, and caught a real mistake in our own modeling before shipping it.
Pricing a bug correctly nearly removed access hundreds of users needed. Why an evidence-based engine must credit service-operation cost without letting it condemn a privilege.
The same project case needs a premium Project Operations license through one door and only Team Members through another. The license is a property of the door, not the destination.
Most tuning decisions turned out not to matter at all. One did, tested across two structurally different clients, and it behaves in opposite directions depending on the client's shape.
D365 charges real licenses for service operations, the endpoints integrations call. Most license tooling prices them as free, so a whole category of paid access is invisible.
Pricing the 'before' seat from the union of every license option a user could reach invents savings that were never there. Price one population, both sides, as a minimum-cost cover.
A vs-compliance baseline and a like-for-like baseline answer different questions and produce very different savings. Mixing them inflates the headline. Name your baseline.
On one estate, five privileges pinned 110 of 127 top-tier seats. License cost is Pareto-distributed, so targeted remediation beats a boil-the-ocean role project.
Only about a quarter of D365 menu items cost less read-only, and a handful of privileges drive most expensive seats. Why 'just make it read-only' rarely lowers the bill.
On one estate the user list held about 2,180 accounts but barely 955 were real people. Counting service and system accounts as seats inflates both the bill and the savings claim.
Roughly half of all menu-item privileges can't be directly observed by any audit trail. Here's the careful, layered process for closing part of that gap.
D365 bills per user over the union of their roles, resolved as a minimum-cost set cover. Pricing per role double-counts and invents savings. The conceptual spine of license analysis.
A disposition table says what to keep, downgrade, or drop. It doesn't say what roles to build. Here's the separate step, and the trade-off it can't avoid.
Microsoft bills per user, not per role, over everything their roles can do. A plain-English primer on D365 F&SC license tiers and the vocabulary every analysis assumes.
A privilege with no recorded activity isn't automatically safe to remove. Why observability has to be verified before silence can be treated as an answer.
Every privilege in a D365 role lands on one of five outcomes. Here's the evidence model behind that decision, and the one rule that keeps it safe to act on.
Every article on this site traces back to the same three-stage method. This piece is the map, linking to the articles that go deep on each stage.
Ten datasets, each answering one specific question, joined together into a single defensible license number.
Clients assume Microsoft-delivered roles are untouched and safe to trust. Five real patterns show how a quietly customized role drives cost.
License requirements aren't decided at the role level. They're decided at the user level, across every role that user holds.
Negotiating a Microsoft discount lowers price per license. It doesn't touch how many you actually need. Two real engagements show what the second lever is worth.
A privilege tied to five expensive workloads doesn't need the priciest one. It needs whatever license every entry point actually shares.
A plain-English breakdown of Dynamics 365 Finance & Supply Chain license types (Team Members, Operations, Premium) and the five overbuying mistakes we see most often.
