That is the maturity curve.
Real-Life Experiences & Best Practices From Projects
Over multiple implementations, I have seen one pattern again and again…
Developer creates:
- A duty extension
- Adds custom privilege into standard duty
Everything works.
Everyone happy.
Until suddenly…
💥 A standard role that earlier required Activity license now becomes Enterprise license.
And people start asking: “Why did licensing suddenly increase after customization?”
This happens because: The highest license from privileges inside the role determines the role license.
And yes…
“Enterprise” is basically Operations licensing in this context
So setting these correctly is NOT optional:
- Menu item license properties
- Entry point access levels
Both matter heavily.
Another Very Common Mistake 😬
Sometimes developers create One giant privilege for one functionality.
Sounds logical initially.
Example:
- Same custom functionality
- Multiple module-specific screens
- Sales version
- Purchase version
- Inventory version
So developer thinks: “Let’s put all menu items into one privilege.”
Now what happens?
💥 Sales user suddenly gets access to Purchase screens.
Not because security is broken…
But because privilege design became too broad.
This is one of the most common over-access issues I see in real projects.
Just because screens belong to same “feature” does NOT mean they belong in same privilege.
Security should follow:
- Responsibility
- User role
- Business process
Not developer convenience 😄
Best Practices We Follow
These practices have worked very well for us across projects.
1. Proper Naming Convention
We always suffix privilege names clearly:
SalesOrder_View
SalesOrder_Maintain
This makes security readable instantly.
When debugging production access at 2 AM…
Good naming suddenly feels like a gift from past-you 😅
2. Separate View and Maintain Privileges
For every Display Menu Item, we create:
- One View privilege
- One Maintain privilege
Example:
CustomerDashboard_View
CustomerDashboard_Maintain
And:
- View privilege → Read access
- Maintain privilege → Create/Update/Delete based on functionality
This gives:
✅ Better control
✅ Better licensing
✅ Cleaner role design
3. Action Menu Items Usually Have Only Maintain Privilege
Because Action menu items perform actions.
Examples:
- Posting
- Processing
- Generating
- Updating
So creating separate “View” privilege usually makes no sense there.
4. Menu Item License Properties Are NEVER Left Empty
This is a very important rule for us.
We always explicitly configure:
- `ViewUserLicense`
- `MaintainUserLicense`
General guideline we follow:
| Operation Type | Typical License |
|---|
| View/Inquiry | Universal |
| Create/Update | Activity |
| Delete | Operations |
Of course:
- Business scenarios differ
- Microsoft standard patterns differ sometimes
But honestly…
This works correctly for more than 90% of customizations.
5. Avoid Extending Standard Duties
This is probably the most controversial one 😄
But in practice: We avoid extending standard duties wherever possible.
Because:
- It can unintentionally elevate role licenses
- Impacts become harder to track
- Future Microsoft updates become riskier
- Auditing becomes painful
Instead:
✅ Create your own custom duty
✅ Document it properly
✅ Ask customer/admin team to assign it to roles intentionally
Slightly more work initially.
Much safer long term.
Final Thoughts
Good security design is not about: “Making access work somehow.”
It is about:
- Least privilege access
- Clean privilege boundaries
- Predictable licensing
- Long-term maintainability
Because one careless privilege design can silently become:
💸 A very expensive customization.
One more important note
I intentionally did NOT include detailed pricing information in this blog because:
- Microsoft licensing may change over time
- New license categories may get introduced
- Pricing may differ by region and agreements
But just to give a rough real-world idea of the impact:
| License Type | Approximate Cost |
|---|
| Team Member | ~$8 |
| Activity | ~$50 |
| Operations / Enterprise | ~$200 |
So when a role accidentally moves from: Activity → Operations
That is not just a “technical change”.
At scale, that can become a very expensive architectural decision 😅
These numbers are only rough indicators.
👉 Always refer to Microsoft’s official licensing documentation for latest and exact pricing details.
Would genuinely love to hear: What security and licensing practices do you follow in your projects?
A developer builds features.
A senior developer builds secure features.
But a great Dynamics architect builds features users can access… without terrifying the licensing team.
