When a Client Says "We Don't Run Commerce, Take It Off Our Bill"

A client who believes their security grew in the wrong direction often wants to drop an entire application, Commerce or Project Operations, because they do not do that kind of work. It is a reasonable instinct and a harder request than it looks, because a D365 license is not a line item you can switch off.

The request, and why it is reasonable

"We are paying for Commerce and we have never run a retail operation in our lives. Take it off." Said in a budget meeting, that is a completely sound challenge. If an organization genuinely has no Commerce processes and no Project Operations work, it should not be carrying those licenses, and a security estate that drifted into requiring them is exactly the kind of thing worth cleaning up.

So the goal is right. The trouble is the mental model underneath it, which is that a license is something you subscribe to and can therefore cancel. In D365 a license is not subscribed to. It is produced, by configuration, one user at a time.

A license is produced, not purchased

D365 decides a user needs Commerce because some privilege in some role they hold reaches a Commerce-licensed entry point. Remove nothing, and the requirement stays no matter how firmly anyone declares the company "does not do Commerce." The invoice is a readout of the configuration, not a menu of optional add-ons.

That means "drop Commerce" is never a single action. It is "find every piece of access in the estate that drives a Commerce requirement, and remove or re-route it, for every user who has it." Until that access is gone, D365 will keep asking for the license, because from the platform's point of view the access to do Commerce work is still there.

Three traps that make it harder than deleting a line

Three specific things get in the way, and all three are invisible if you treat the license as a checkbox.

The tie trap. Many privileges accept more than one license. A privilege that needs "Commerce or Supply Chain Management" is satisfied by either. When the two cost the same, D365 breaks the tie in an undocumented direction, and in practice it has been observed naming Commerce even when SCM would have covered the user. While that tie stands, you cannot remove Commerce by reconfiguring roles, because the platform may keep picking it. The only way to get Commerce off those users is to remove the tied access itself. (See the companion piece on how D365 breaks price ties.)

The optimizer-puts-it-back trap. If your analysis simply tells the cost engine "this app is forbidden" but leaves the access in place, a cost-minimizing engine will re-introduce the app wherever it is the cheapest way to cover a privilege. Forbidding the license in the options list is not the same as removing the access, and the engine will quietly route back to it unless the access is actually gone from every kept privilege.

The per-user trap. Even after you strip Commerce from one role, a user keeps the Commerce requirement if any other role they hold still reaches Commerce access. A role cannot hold a license, so "we removed Commerce from the Retail Clerk role" guarantees nothing for a user who also holds a second role that needs it. The removal has to be confirmed at the user level, across everything they hold. (See the companion piece on why a role cannot have a license.)

What "drop Commerce" actually requires

Put together, the honest version of the request is a project, not a toggle:

• - Find every privilege in the estate that drives a Commerce requirement, including the tied "Commerce or X" privileges and any hidden in service operations.
• - For each, decide: is this access genuinely unused (drop it), reachable a cheaper way (substitute the entry point), or actually needed by someone (then the app cannot be fully dropped, and that is a finding).
• - Resolve the ties by removing the tied access, not by hoping the platform picks the other side.
• - Confirm, per user, that no remaining role re-introduces the requirement.
• - Produce the list of exactly what each affected user loses, in plain language, before anything is removed.

Done properly, a client that truly has no Commerce operations can usually get there, and the saving is clean and large. The point is that it is configuration surgery with a sign-off, not an instruction you can action in the admin center.

Our adjustment: a license-intent ledger, not a one-time file

The request "we should not be paying for Commerce" is not a one-time cleanup, because a live estate drifts. A role edited six months from now can reach back into Commerce access and quietly put the license back. So we are moving these instructions out of spreadsheets and into standing governance.

The design we have committed to works like this. A client's "forbid Commerce across the estate" becomes a rule in an append-only intent ledger: a scope (the whole estate, or a named set of roles), a verb (forbid, allow as an exception, or cap at a maximum tier), and a version stamp. Each new data snapshot then re-checks the active intents against the current configuration, so a role that drifts back into needing a forbidden app is flagged, not silently billed. And no rule authorizes a removal on its own. The client signs a separate, plain-language consequence list naming the specific menu items users will lose, because a one-line "forbid Commerce" should never be allowed to silently approve stripping real functionality from dozens of people.

Pros and cons of dropping a whole app

For it: if the organization genuinely does not do the work, the access is pure risk and pure cost, and removing it both shrinks the bill and tightens least privilege. The saving tends to be large and durable, and the compliance story is strong, because you can show exactly why no user needs the app.

Against it, or at least to be careful about: "we do not do Commerce" is a claim to verify, not a given. A rarely-used but real capability (a single annual process, one integration, one team nobody thought of) will surface as the one user who genuinely needs the app, and dropping it anyway is an outage waiting to happen. The work is also real: ties, service operations, and per-user confirmation are exactly where a naive "just remove it" goes wrong. And it is ongoing, because drift will try to undo it.

Bottom line

"We do not run Commerce, take it off" is a great hypothesis and a poor instruction, because a D365 license is produced by configuration, not purchased as a line. Turning it into a real, clean removal means finding and removing the access that drives the app, resolving the ties, confirming per user, and governing against drift, with the client signing off exactly what each person loses. Do that and the saving is real and defensible. Skip it and you have either a number the platform contradicts or a user who cannot do their job.

Frequently asked questions