Roles, duties, privileges, and the segregation-of-duties conflicts auditors check first.
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.
A client deployed a full security-role redesign straight to production without a UAT pass of the shipped build, and the first business day was quiet. Why an additive, evidence-built cutover makes that safe, and what it does and does not prove.
How two Dynamics 365 clients went live on a new security design without a UAT pass of the shipped build, and why the weeks of data collection beforehand are the test that makes a fast, low-risk go-live possible.
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.
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.
Grant/deny conflicts, mixed-tier privileges, sysadmin-plus-business-role overlaps: none of it needs usage evidence to catch. Here's why the lightest check we run is worth running after every security change during remediation, not just once at the end.
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 client chose to deliver their security redesign in batches, a completely reasonable call for a business that can't pause. Here's what that decision actually costs on our side, batch after batch, and why it isn't anyone's fault.
Cost came first, then it came third, out of a legitimate concern about revoking access without proof of use. Remediation exists to cut a real bill, so we adapted our strategy to keep finding savings compatible with the new order.
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.
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.
Our evidence model leans on telemetry and audit-log evidence together. This environment had almost no usable telemetry at all. Here's what the redesign looked like on one evidence source instead of two.
Our cheapest role-mining design still produced 760 roles. The client asked for as few roles as possible, and told us upfront they'd pay more for it.
A client rejected a 100-role fix and asked us to mine roles from real usage instead. Our first attempt would have cost more per month than doing nothing.
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.
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.
Most reviews start with a user list and a role count, about ten questions. A properly scoped intake runs to 106. Here's what falls in the gap.
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.
The security model wasn't the biggest driver of this estate's license bill. The way one integration authenticated was.
Instead of two hours of manual UI exports, get just-in-time database access to a Tier 2 sandbox and run one script that pulls all 33 datasets, license, security, personalization, and audit-log evidence, unattended.
Four published engagements with real before-and-after numbers, including the one where our own recommendation got turned down, and why we publish that one too.
Ten datasets, each answering one specific question, joined together into a single defensible license number.
A role name rarely tells you why it's expensive. The entry points inside it do.
Clients assume Microsoft-delivered roles are untouched and safe to trust. Five real patterns show how a quietly customized role drives cost.
A mentoring engagement on a greenfield D365 F&SC implementation found over a thousand segregation-of-duties conflicts in thirty roles, a day before user acceptance testing. What doing security right the first time actually looks like.
Our first fully automated D365 F&SC security migration: an XML import replaced weeks of manual role-building. What that automation actually required, and the framework we had to build around it.
The mathematically optimal security model saved $32,000 a month. The client rejected it as unmaintainable, and was right to. Why, and how we rebuilt our methodology because of it.
A European estate with genuinely well-built security still carried $40,000 a month in avoidable license cost. What a clean configuration hides, and how we found it anyway.
A four-export, two-formula method for finding exactly which permissions drive each license on a role that requires three or more, plus a free downloadable workbook.
Contradictory Deny/Grant on the same entry point, and Correct or Invoke permissions granted without their prerequisites. Both pass an access review clean and still inflate license tiers.
How D365 F&SC's role/duty/privilege security model works, the SoD conflict pairs that show up most often, and a walkthrough of running your own analysis.
