"This Role Should Be Cheaper If People Worked Differently"

Sometimes a client points at a role and says the people on it should not be driving a Project Operations or Commerce license. They should change how they work and consume a cheaper one. That is a legitimate instruction, and modeling it correctly is more than deleting a license from a spreadsheet.

The instruction

It usually arrives as a business judgment, not a technical request. "The technicians on this role do not need to be full Project users. They log a few cases. If they did that a simpler way, they would not need the expensive license." The client is not asking you to hide a cost. They are proposing a process change and asking what it is worth.

That is a good instinct, because it targets the real lever. The license is driven by what the role lets people do, so changing what they do, or how, is exactly how the requirement comes down. The job is to turn the instruction into a modeled target state that is honest about what it costs the people on that role.

Why you cannot just "remove the license from the role"

The naive version is to open the model, find the role, and set its license to the cheaper tier. It does not work, for three reasons that all trace back to how D365 actually bills.

A role cannot hold a license. D365 bills per user, over every role they hold, so "make this role Team Members" is a statement about a thing the invoice does not have. The role's contribution matters only through the users on it.

The cost engine will put the license back. If you forbid the expensive license in the role's option list but leave the access that needs it in place, a cost-minimizing engine re-introduces the license wherever it is still the cheapest way to cover a kept privilege. You have to remove the license from every kept privilege in the role, not just mark the role as cheaper.

A tie is a failed exclusion. If a privilege in the role accepts "Project Operations or SCM" and the two tie on price, D365 may keep naming the expensive one, and no amount of relabeling the role changes that. The tied access has to go, or the exclusion has not happened.

What the instruction actually means

Translated, "this role should be cheaper if people worked differently" is: find the specific access in this role that drives the expensive license, and either re-route it to a cheaper entry point that does the same job, or drop it, then confirm the users on the role actually fall to the cheaper tier.

That is three concrete moves:

• - Identify the driver. Which privilege, and which entry point inside it, is forcing the expensive license. The role's name never tells you this; the entry points do.
• - Substitute or drop it. If the same outcome is reachable through a cheaper-licensed door, re-route to it. If it is genuinely unused, drop it. If it is needed and has no cheaper door, the process change is not free, and that is the honest answer.
• - Confirm per user. The users on this role may still need the license through a different role they hold. The tier only actually drops for the users for whom this role was the last thing driving it.

The worked example: project cases

The clearest version of this is a client whose technicians were driving a Project Operations license purely by creating and maintaining project cases through the project-case forms. The client's judgment was that these people did not need to be full Project users to log a few cases.

They were right, and the fix was a process change plus a targeted removal. The same case can be created from the generic Common area and linked to the project, which is a Team Members operation, and viewed back under the project, also Team Members. So the target state re-routes case creation to the generic door and drops the privilege responsible for project-case creation and management. In that target state, once the privilege is gone and the cheaper path is in place, the affected users no longer need Project Operations: about 57 move to a cheaper license, roughly 26 of them a full tier down and the rest more modestly. (As of this writing the change is built and reviewed but not yet deployed; the figures are the modeled target. See the companion piece on how the same action through a different entry point carries a different license.)

That is the shape of every "this role should be cheaper" instruction done well: a named driver, a cheaper equivalent path or a clean drop, and a per-user confirmation that the tier actually fell.

Expressing it as a ceiling

A useful way to capture the client's intent without pretending a role holds a license is to express it as a ceiling on the role: this role must cost no more than Team Members, or no more than Activity. A ceiling is unambiguous and it survives drift. It says "whatever privileges end up in this role, none of them may drive a license above this tier," which is exactly the client's instruction, phrased as a constraint the model can enforce and re-check on every future snapshot.

Show the client what the process change costs

A process change is never free to the people living it, even when it is free on the invoice. Re-routing case creation means a different menu path and, in that example, giving up the right to delete a case through that form. Those are small, but they are real, and the client has to see them before they approve.

So the instruction is modeled as intent, never as approval. The output is a plain-language consequence list: here is the cheaper tier these users land on, and here is exactly what changes about how they work to get there. The client signs that, not a one-line "make this role cheaper." A spreadsheet entry should never be allowed to silently approve a change to how dozens of people do their jobs.

Bottom line

"This role should be cheaper if people worked differently" is a legitimate, modelable instruction, as long as you model it the way D365 actually bills: find the access that drives the expensive license, substitute a cheaper equivalent door or drop it, express the client's intent as a ceiling on the role, and confirm per user that the tier actually fell. Then show the client exactly what the process change costs the people on that role, and let them approve that, not a label. Done this way, the client's business judgment becomes a real saving with no surprises.

Frequently asked questions