Reaching an identical business outcome through a different entry point can require a different D365 license. Re-route users to the equivalent cheaper-licensed door and the data, the workflow, and the result stay the same while the bill drops a full tier.
A client asked us to solve their Project license consumption
The request came from the client. Their technicians were consuming a Project Operations license purely through a couple of menu items: creating and maintaining project cases through the dedicated project-case forms. The client asked whether there was a way to keep the work and lose the license.
There was, and it was a process change rather than a cut. The same cases, with the same fields and the same downstream linkage, can be created from the generic Common area, linked to the project, and read back under the project, and every one of those steps requires only 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, roughly 57 users move to a cheaper license, with about 26 of them dropping a full tier off Project Operations and the rest moving down more modestly. (As of this writing the change is built and reviewed but not yet deployed, so this is the modeled target, not yet the invoice.)
The gap between those two tiers, across those users, came to $56,820 a year. Nothing about the work changed. Only the door changed, plus one privilege that nobody needed once the door moved.
Why the Door Decides the License
D365 does not price "a project case." It prices the entry point you use to touch one. Microsoft assigns a required license per privilege and per entry point, so two menu paths that land on the same record can carry two different license requirements.
For project cases the split is concrete:
- - Writing through the project-case forms (`CaseDetailNewProject` and `CaseDetailProject`) requires Project Operations.
- - Creating the same case from Common > Cases (the `CaseDetailNew*` forms) is a Team Members operation.
- - Linking that case to a project with `CaseConnectToProject` is a Team Members operation.
- - Viewing it afterward under Project > Related > Cases (`CaseListPage`) is a Team Members operation.
A user who creates the case under Common > Cases, links it with `CaseConnectToProject`, and reads it back under Project > Related > Cases has done everything the project-case form user did, and has stayed inside Team Members the whole time.
One detail worth keeping: read access on the project-case forms themselves is also Team Members. So you keep the read privilege on those forms. You are not stripping the forms out of the role. You are removing only the write path that pins the Project Operations license.
The General Pattern: Entry Point Substitution
This is a repeatable optimization category, not a one-off project-case trick. The pattern is:
- 1. Find a privilege whose required license tier is higher than the role needs.
- 2. Identify the entry point driving that tier.
- 3. Check whether an equivalent entry point reaches the same data and the same outcome at a lower tier.
- 4. Re-route the user to the cheaper door and remove only the expensive one.
The savings come from the fact that the user's actual job never required the expensive door. They required the outcome. D365's license model lets the same outcome arrive through doors of different prices, and most role designs reach for whichever door the original app designer wired to the ribbon button, not the cheapest compliant one.
Where This Shows Up
Entry-point substitution tends to pay off where a specialized module's forms duplicate functionality that also exists in the general Common area:
- - Cases and project cases, as above.
- - Records that can be created generically and then linked to a module, rather than created inside the module.
- - List pages and "Related" views that read a record versus the module-native form that both reads and writes it.
The test is always the same question. Can the user reach this exact record, with the same fields, through a door that D365 licenses lower? When the answer is yes, the higher door is a cost with no corresponding capability.
Do Not Substitute Blindly
Two guardrails keep this honest.
First, substitution is a per-user decision. If several users share a duty and some of them genuinely write through the expensive form, swapping the duty's privilege strips write access from the people who need it. Move the privilege on the individual role or cohort, never on a shared duty that write users depend on.
Second, verify before you promise a dollar figure. The only reliable proof that a door drives a license is a removal test: take the expensive entry point out in a sandbox and confirm the required license actually drops, with a known-good control that should not change. Re-route the users, then confirm the tier fell.
Bottom Line
The license you pay is a property of the door, not the destination. Before you accept a Project Operations seat (or any premium seat) as the cost of a workflow, find out whether the same record is reachable through a Team Members door. At one client that single question was worth $56,820 a year.
Frequently asked questions
Does the user notice the change?
They use a different menu path to reach the same record. The data and the outcome are identical. The difference is where they click, not what they accomplish.
Is this a licensing loophole Microsoft will close?
No. It follows Microsoft's own per-entry-point licensing. You are using the license tier Microsoft attached to the door you actually use. The risk is the reverse, that you are overpaying for a door you never needed.
How do I find these across a whole tenant?
Start from privileges whose required tier exceeds their role's baseline, then check each one for a lower-tier entry point that reaches the same table. The high-value targets are usually few.