Almost No Telemetry, Still a Defensible Number: A Small D365 Environment's Redesign

Every case study we've published so far shares one thing in common: a real, working feed of navigation telemetry to lean on. Our evidence model is built around two sources, telemetry showing what a user opened, audit-log activity showing what they actually wrote. This engagement had almost none of the first kind. A small D365 environment, under a hundred licensed users, with usage telemetry that amounted to a handful of recorded events across the entire population. This is what the redesign looked like when one of our two evidence pillars was, for practical purposes, missing.

What happens when one evidence source goes quiet

The five-outcome model doesn't require both evidence sources for every privilege, it's built to degrade honestly when one goes missing, not to fail. Without telemetry, one specific verdict becomes much rarer: downgrade_to_read is earned by telemetry showing navigation with no write, so with telemetry essentially absent, we lose most of our ability to distinguish "opened but never wrote" from "never touched at all." What's left carries more of the weight: audit-log write evidence directly earns stays_as_is, and everything the audit trail can't reach falls to the same guardrail we've written about before, kept and flagged for review, never dropped for lack of evidence the system had no way to produce here regardless of client size.

A genuinely different shape of client

Past the evidence gap, this environment looked structurally different from the larger, integration-heavy organizations we've covered elsewhere on this site. Roles here were largely homogeneous, most people holding a given role needed close to the same access as everyone else in it, and the population was small enough that the entire redesign, strict floor through fully consolidated, produced job-family counts you could list on one page.

The same two-design split from our other work still applied. The strict design, one role per job family per license tier, priced out at roughly $38,000 a year, with roughly 8,700 individual, one-off grants left over, the same unmanageable-tail pattern we've seen on every strict run regardless of client size. The consolidated design, one shared role per job family with the leftover tail fully reabsorbed, came in at roughly $59,700 a year, with zero individual grants remaining.

That's a roughly 57% consolidation premium, proportionally the largest we've measured, and it's exactly the pattern our cross-client parameter study predicted: a smaller, more homogeneous population feels the cost of consolidating far more, in percentage terms, than a large, tier-diverse one does, even though the underlying mechanism is identical. The honest way to present that number to a client this size isn't "57% more," it's the actual dollar amount, roughly $21,700 a year, to retire thousands of ungovernable one-off grants. The percentage looks alarming in isolation; the dollar figure is what a finance team can actually weigh.

The one cleanup step that wasn't free here

On our largest published engagement, closing the very last individual grants down to zero cost nothing, the leftover buckets happened to land on people who already held that license tier for other reasons. Here, the same final cleanup pass added a modest amount to the bill, a few of the last remaining grants landed a handful of people on a slightly richer tier than their own evidence alone required. Neither outcome is a rule. Whether the last mile of consolidation is free or has a small price is a property of each client's own data, which is exactly why we test it rather than assume it.

A setting that behaved safely here, dangerously elsewhere

Our parameter study flagged one tuning decision, how generously a shared role absorbs a privilege most but not all of its members need, as the single setting most dangerous to reuse across clients. On our larger, tier-diverse client, loosening it too far caused a real cost blowout. On this environment, the same setting stayed safe across a wide range we tested, because its roles were already close to single-tier to begin with, so sharing more aggressively simply doesn't have much room to go wrong. That's not a coincidence we got lucky on twice, it's the finding itself: the same setting is safe or dangerous depending on how tier-diverse a client's actual job functions are, not on how big or how "similar on paper" the client looks.

What we'd tell the next small client

• Missing telemetry doesn't disqualify the method, it changes its shape. Expect fewer read-only downgrades and a larger review-and-decide list, not a less defensible result.
• A small, homogeneous population feels consolidation costs harder, proportionally. Frame the trade-off in dollars, not just percentage, or a genuinely reasonable number can look alarming out of context.
• Never assume a setting that was safe on one client stays safe on the next. The size of your organization tells us almost nothing about which settings are safe; the shape of your actual job functions tells us everything.

Questions we get asked