In Dynamics 365 Model-Driven Apps, the Sitemap defines the navigation structure users interact with daily. While it seems straightforward — “add entity, set order, group items” — many implementations fall into avoidable traps that lead to data overexposure, UI inconsistency, or unexpected access.
This article breaks down how Sitemap visibility really works, how App Designer interprets role permissions, and what common missteps can cause issues — based on real-world enterprise experience.
How Sitemap Visibility Works
When you include an entity in a Sitemap (via App Designer), whether a user can see it depends not only on:
- Whether the entity is added to the App
- Whether the user has a role assigned to the App
- Whether the user has privileges (like Read) on that entity
But also:
- Whether App-level Role Filtering is enabled (via “Manage Roles”)
- Whether the user’s Security Role includes Share/AppendTo/Read privileges
- Whether any custom control or JavaScript further affects visibility
Common Pitfalls in Sitemap Permission Design
(a) Assuming “Read” access is enough
Case: A Sales Rep (SR) role has Read access to a custom table Contact Segment, but it doesn’t appear in their app.
Cause: The App’s Role filter doesn’t include SR role, or the entity wasn’t part of the app at build time.
Fix: Assign proper role to App (via Manage Roles) and ensure the entity is added to the App.
(b) Newly added entities bypassing role-based filters
Case: After go-live, a developer adds three tables to the “Master Management” section. Suddenly, SR users can see it — although they were never supposed to access this area.
Root Cause:
- Sitemap updated without re-validating “Manage Roles”
- The new entities inherit visibility from the app, not from previous restrictions
Fix: Always re-check Manage Roles after every Sitemap or App modification.
(c) Misplaced Area/Group confusion
Case: A table intended only for managers (like User Control Panel) is placed in the “Sales” area. SR users don’t have permission to open it, but they still see the tab and get an error on click.
Fix: Review Sitemap structure during UAT — not just for functionality, but for clarity and access alignment.
what App Designer Doesn’t Tell You
- App Designer’s “Manage Roles” only controls which roles can access the App
- It does not prevent users from seeing all Sitemap items unless those items are also role-restricted via Security Role
Gotcha: When new entities are added after go-live, developers may not realize they need to manually replicate role assignment logic.
Consultant’s Language – How to Explain to Clients
Here are a few real-world phrases you can use to set expectations or explain fixes clearly:
- “Even though we restricted access via roles, Sitemap visibility must be aligned separately in App Designer. They don’t sync automatically.”
- “Just because a user can ‘see’ a tab doesn’t mean they can open it — but ideally, they shouldn’t see it at all. Let’s clean that up for user clarity.”
- “Each time we add a new table or update the App, we need to reapply the same role logic — think of it as refreshing the access rules manually.”
- “This is a limitation of the platform. It’s not a bug, but rather a behavior we need to manage properly during each release.”
Best Practices Going Forward
Maintain a clear App-Roles-Permissions matrix
Validate Sitemap updates in each UAT cycle
Use role-specific Apps (e.g., SR App, Manager App) if the system complexity justifies it
Document Sitemap change control as part of your ALM
Conclusion
Sitemap visibility is deceptively simple — but without deliberate control, it can undermine the security and UX of your Dynamics 365 environment.
As consultants, we should treat Sitemap governance as seriously as data security and form logic, and communicate clearly with clients that Sitemap ≠ Permissions, unless both are explicitly designed in sync.
コメント