Only about a quarter of D365 menu items actually cost less at the read tier, and when they do the drop is almost always just to Team Members. Read-only is a targeted lever, not a mass savings strategy, and lowering a tier in place saves nothing at all.
About Three Quarters of Menu Items Cost the Same Read-Only
Across D365 menu items, only about a quarter have a read tier that is cheaper than their write tier. The other roughly three quarters cost exactly the same whether the user can edit or only look. Making those read-only changes the user's capability and changes nothing on the invoice.
When read is cheaper, the drop is almost always to Team Members and no lower. There is no deep discount hiding below. The realistic best case for a read-only substitution is "this privilege falls to Team Members," applied to the minority of privileges where a cheaper read tier exists at all.
A Full-Only Privilege Stays Full, Even Read-Only
Some privileges have no cheaper read tier because their license requirement is Full with no lower option. Making one of those read-only does not move it. A Full-only privilege keeps its Full license name even when the user can only read. Commerce read still needs Commerce. Finance read still needs Finance.
So "read-only" is not a universal downgrade button. It only helps where a genuinely cheaper read tier exists for that specific privilege, and for a large share of privileges one does not.
Lowering the Tier in Place Saves Nothing
Here is the trap that makes read-only projects underdeliver. Taking an existing write privilege and relabeling it as read, or dialing its tier down in place, saves nothing. The privilege still ships at its write tier.
To actually capture a saving you have to substitute a real read-only privilege. That means either an existing read-only sibling of the privilege (a `*View` object the client may already own) or a newly minted read-only version. The user ends up holding a different, genuinely read-only privilege. Until that read-only privilege actually exists and ships, the write privilege is what gets delivered and priced, at the write tier.
This is why "we set it to read-only" and "we lowered the bill" are two different claims. The first is a configuration state. The second requires an actual read-only privilege to have replaced the write one, per user, verified.
Check Your Own Library First
Before minting a new read-only privilege, look for one the client already has. Clients often already own no-delete or view-only versions of the exact privileges you are about to recreate. Minting a duplicate of an object that already exists just gives the client another thing to maintain. Reuse the existing read-only sibling when there is one.
Target the Few Privileges That Pin Everyone
The reason a mass "make everything read-only" curation project is the wrong shape is that cost is usually concentrated. At one client, 5 privileges pinned 110 of 127 Full-seat users to their Full license. Five. Not fifty, not five hundred.
That is the Pareto point. A handful of privileges hold most of your expensive seats in place. Finding and handling those few, with a per-client exception list and specific questions to the client about each one, beats combing through thousands of privileges hoping to shave tiers. The curation project costs real effort and mostly touches privileges that were never going to change the bill. The targeted approach goes straight to the privileges that actually pin seats.
How to Prove a Read-Tier Saving
Because so many read-only changes save nothing, do not quote a saving until you have proven it. The proof is a removal test in a sandbox: take the privilege out, or swap in the read-only substitute, and confirm the user's required license actually drops. Run it with a control that should not change, name an owner for the process, and read the admin center's license view late rather than trusting it mid-change. A read-tier saving that has not survived a removal test is a hypothesis, not a number.
Bottom Line
"Make it read-only" is a precision tool, not a bulk discount. It pays off on the roughly one in four privileges that have a cheaper read tier, only when you substitute a genuine read-only privilege rather than relabeling the write one, and it never touches Full-only privileges. Go after the handful of privileges that pin most of your Full seats and prove each saving with a removal test. Skip the tenant-wide curation project.
Frequently asked questions
If I make a privilege read-only, does the user's seat get cheaper?
Only if that privilege has a cheaper read tier and you substitute an actual read-only privilege. For about three quarters of menu items the read tier costs the same, and for Full-only privileges it stays Full regardless.
Why did our read-only change not lower the bill?
Most likely the tier was lowered in place rather than substituted with a real read-only privilege, so the write privilege still shipped at the write tier. Or the privilege had no cheaper read tier to begin with.
Where should we focus if not everything?
On the few privileges that pin the most Full-seat users. At one client, 5 privileges held 110 of 127 users on Full. Handle those with a per-client exception list and questions to the client.