Most license optimization engagements end with one recommendation. This one ended with three, because the client's real decision wasn't about security cleanup at all. It was about whether to change how a piece of software talked to Dynamics 365 Finance & Supply Chain in the first place, and that decision was worth roughly $170,000 a month on its own, before a single role got touched.
An estate built around one integration point
The environment runs on an unusual pattern: nearly the entire user base interacts with the business through an external application, not through D365 F&SC directly. That application, a Power Apps or model-driven front end, collects transactions, sales orders, purchase orders, and everything in between, then transmits the resulting data into Finance & Supply Chain.
The transmission itself was the detail that mattered most. It happened using the credentials of a real, named user account, one that existed as an actual user inside both the external application and D365 F&SC. Every transaction landed in Finance & Supply Chain with a timestamp, a CreatedBy, and a ModifiedBy attributed to a person who had, in a great many cases, never once opened the D365 interface.
With roughly 1,000 active users and a security configuration sized to match, the fully-licensed monthly requirement, if nothing changed, came to approximately $260,000. Just under 1,000 Supply Chain Management licenses, over 200 Finance attach licenses, around 40 Finance base licenses, and a comparable spread of Project Operations and Commerce attach licenses. A striking number of licenses for the work actually being described.
Two roles were doing almost all of the damage
More than thirty roles assigned to users required more than one license, in varying combinations of Finance, Supply Chain Management, Commerce, and Project Operations. That alone was expensive. But the sharper finding sat inside two specific roles acting as the integration's actual entry points.
One was a Team Member role. Assigned to essentially the whole user base, it was cheap by design, close to $8 a month per user. The other integration role was not. It required Supply Chain Management, Commerce, and Project Operations at once, three licenses total, one base and two attached, and it was assigned to several hundred people. At current pricing that worked out to roughly $270 a month per person carrying it, purely for functioning as a conduit between two systems.
An integration point doesn't have to be expensive by nature. It's expensive when it's built to authenticate as a person instead of as a service.
The activity picture, once we looked
Several hundred users had never logged into D365 F&SC at all. Several hundred more hadn't logged in for four months or longer. We don't assume that means they're genuinely inactive, and in this case the evidence agreed: their real work almost certainly happened entirely inside the external application, with D365 F&SC only ever seeing the transactions that application transmitted on their behalf. From the system's own perspective, though, there was no operational reason to keep most of these accounts licensed as active named users.
A separate, smaller finding was worth flagging even though it wasn't a savings lever: a meaningful number of system administrators were also holding genuine business roles. Not a cost driver today, but exactly the kind of combination worth explaining before an auditor asks about it first. Partner accounts told a related story. Several were assigned Team Member security roles, when partner accounts should generally be license-exempt entirely. They weren't configured that way here, so they were quietly consuming licenses that shouldn't have applied to them at all.
The permission discrepancy hiding inside "read-only"
The most technically interesting finding, and the easiest one to miss without deliberately looking for it, showed up in a set of custom privileges. On the surface, they granted read access only, nothing more. Underneath, several of them still carried a granted Correct permission, left over from configuration that had been edited in place rather than rebuilt cleanly. That permission would never actually be reachable in normal use, since the lower-level access it depends on was unset. It didn't matter. The license engine doesn't check whether a permission is functionally reachable. It checks whether it's granted, and a granted Correct permission on an expensive object pulled the entire privilege up to a full Finance or Supply Chain Management requirement, invisibly, on top of what everyone assumed was a harmless view-only role.
A related pattern showed up the other direction: privileges that denied read access to an object outright, while every other permission level on that same object was granted. Functionally, that combination grants nothing at all, since none of update, create, delete, or correct can be exercised without read access underneath them. The license requirement didn't know that. It still counted the higher-level grants and required a full license for access the configuration itself had made impossible to use.
Both patterns cost real money for access nobody could actually exercise. Neither would show up in a review that only checked whether a role's name matched its intended purpose.
Three options, not one recommendation
Once the analysis was complete, we didn't hand over a single number. We laid out three, because the client's real decision was architectural, not just operational.
Do nothing. Keep the current configuration, keep the named-user integration pattern, and continue paying approximately $260,000 a month.
Reconfigure security, keep the architecture. Clean up the permission discrepancies, remove the license-inflating grants, right-size the inactive population, and bring the monthly requirement down to roughly $180,000, without touching how the integration authenticates.
Rework the integration itself. Replace the named-user credential doing the data transmission with an application user or service account, the same architectural pattern Microsoft's own dual-write functionality uses, so the integration no longer consumes a named-user license at all. Paired with telemetry-driven optimization of the roles, duties, and privileges that remained genuinely in use, this option brought the estate to approximately $90,000 a month, close to a two-thirds reduction from the starting point.
The gap between the second and third options is the real lesson here. Security cleanup alone, careful and thorough as it was, could only ever recover part of the opportunity, because the biggest cost driver in this estate was never really a security design problem. It was an authentication choice made when the integration was first built, one that happened to route through a person instead of a service account, and kept billing that way ever since.