Thirty Roles. A Thousand Conflicts. One Day Before UAT.

Thirty roles held more than a thousand segregation-of-duties conflicts between them, on an implementation that hadn't gone live yet. The design was found to be a day before user acceptance testing began. There's no dollar figure attached to this one. There's something more useful: a repeatable answer to the question every security practitioner should be forced to answer at least once.

This case study is different from the rest of this series. There was no client engagement behind it. It began with a request for mentoring.

A different kind of engagement

A functional D365 Finance & Supply Chain consultant with five years of experience asked us for guidance on one of his implementations. He knew how to configure security, assign roles, and track down missing permissions; the mechanics were never the problem, theoretically or practically. What he was looking for was the accumulated wisdom of security: the industry knowledge that only years of analysis, optimization, and remediation build up. The arrangement was simple. He would do all the work himself, with a mentor walking alongside to sanity-check the small steps.

His opening question is the one every security practitioner should be forced to answer at least once: starting completely from scratch, a brand-new implementation, a brand-new requirement, where do you begin?

This was genuinely from scratch, the ideal scenario. The business had written its requirements as a free-form, informal request: tasks they considered securable, described in their own language, the roles they wanted, and a spreadsheet granting access to those tasks. No legacy roles, no inherited configuration, no years of drift. A blank page.

First principle: don't build the everything-role

Years of security work produce habits that operate on intuition, and a greenfield project is the rare chance to turn them back into explicit rules. The first one surfaced immediately: do not put all permissions into one role.

The temptation is obvious. One user, one role, what could be easier to manage? But that simplicity is an illusion, and it collapses the moment the organization starts moving. People transfer between departments and need new access. People take a break and delegate their duties to colleagues. People pick up new assignments and new responsibilities. Every one of those events forces a change, and when roles are huge containers holding everything a person might touch, every change becomes surgery on a monolith.

What works instead, arrived at intuitively on this project and now stated as a rule, is roles that stay close to actual business roles, with configuration organized around business tasks. Small enough to move. Meaningful enough to reason about.

Who should be doing security, anyway

The consultant did all the configuration himself, collecting duties around the tasks the business had defined and occasionally pulling in his mentor to pin down what users actually wanted. And along the way, he arrived independently at a complaint that mirrors a long-held belief in this practice.

Anyone doing security configuration, he observed, needs to know Finance & Supply Chain from the inside out, as deeply as possible, to understand the business need, the functionality behind it, and the technical side required to translate one into the other. At times he felt his own functional knowledge falling short, and he said so.

Security configuration is not a task for a junior developer. It's as important as data migration, as functional configuration, as the architecture of the system itself. The person doing it must understand absolutely all of the functionality in Finance & Supply Chain, must understand the business, and must understand what's actually at stake. It's routinely staffed as if none of that were true.

"Just in case": the requirements problem

Reviewing the client's requirements, one pattern jumped out immediately and was raised more than once during mentoring: the proposed roles were configured wide.

In real life, no one takes care of everything, unless it's a ten-person shop where everybody does anything and everything themselves. In a real company, segregation of duties exists whether anyone designs it or not; it emerges naturally from how work divides, or it gets enforced deliberately. The roles the business proposed ignored that reality. An accountant was granted treasury functionality, just in case. Everyone received full access to projects, project budgets, project accounting, just in case.

The spreadsheet was saturated with just-in-case access, and to an experienced eye the problem was unmissable. The recommendation followed naturally: run a segregation-of-duties analysis before this design goes anywhere near production.

Thirty roles, one thousand conflicts

The environment had only about 30 roles. The segregation-of-duties analysis found over a thousand conflicts in them.

The point had been made repeatedly during mentoring: certain permissions should never coexist in a single role, never mind a single user; these combinations shouldn't survive inside one role. After enough repetition the consultant agreed to run the analysis, and the numbers made the argument on their own.

When he brought the results to the business, with the standard reasoning that accompanies segregation-of-duties violations, the business side was in shock. They had never thought about their own requirements this way. It had never occurred to them that a requirements spreadsheet could itself be a source of risk: a generator of user-related human error, and a standing invitation to potential fraud. They had written down access. They had not written down consequences.

The question: what do you do, one day before UAT?

Then came the hard part. This conversation happened essentially a day before user acceptance testing. Too late to redesign the security from scratch. Not too late to redesign and retest; a few months still remained before go-live, but far too late for a blank-page do-over.

The consultant asked his mentor directly: in his shoes, what would you do?

The advice: turn telemetry on, let the users test everything, and bring the data back to the business as evidence, evidence that users almost certainly don't need as much access as the requirements granted them.

And, deliberately, the advice wasn't to propose the least possible access. Pure minimum-viable access, imposed a day before UAT on a business that has just discovered segregation of duties exists, is a fight nobody wins. The proposal instead was the position between the two extremes: build the roles so that segregation-of-duties violations are minimized, not eliminated at any cost, not ignored, but driven to the minimum the business can genuinely operate with. And build those roles from telemetry, from what people actually do during testing, not from what anyone guessed in a spreadsheet.

What happened next

Telemetry went on, and user activity during testing began shaping the roles, still fewer than thirty of them, so that users could carry out all of their real functionality without tripping over missing access, and without the just-in-case sprawl.

When the proposals reached the business, they confirmed what the whole exercise had been pointing at: they had never considered that overly wide access could itself cause problems, and they genuinely hadn't known what people would actually need. That's why the requirements were written just-in-case, not carelessness, simply the honest absence of information. Telemetry supplied the information.

Why this case matters

There's been no formal license analysis on this project. No savings figure, no before-and-after. The engagement was a proposal for how to do it right the first time, and that's exactly what makes it worth writing up.

Every other case in this series is archaeology: environments analyzed years into production, where just-in-case access has compounded into real monthly invoices and hundred-role remediation projects. This engagement is the counterfactual. Telemetry isn't only a remediation tool; it helps at the very beginning, while the system is still being configured, before go-live. It shows what will actually be used. It heads off the expensive configuration before the configuration exists. And one honest conversation about segregation of duties, held at the requirements stage instead of the audit stage, prevents an enormous amount of post-go-live headache and saves real money.

The project is ongoing, and the mentoring continues. What's worth watching for is whether doing it right the first time looks, in the numbers, the way it should.

This is the fourth in a series on D365 license optimization and security. The first covered an integration-heavy environment where the standard playbook failed. The second covered a client whose excellent security was still 35% overpriced. The third covered a fully automated remediation delivered in ninety minutes.