Sitemap customisation in model-driven apps

The site map of a model-driven app — the left-side navigation menu users see — is the structural backbone of how they experience the app. Customising it well makes the app feel coherent and on-purpose; leaving it as Microsoft's default leaves users with menu items they don't recognise and missing items they need.

The hierarchy.

• Area — top-level grouping. A button at the bottom of the navigation lets users switch areas. Example areas: Sales, Service, Marketing, Settings.
• Group — a label within an area, dividing related items. Example groups within Sales: My Work, Customers, Sales, Marketing Lists, Goals, Tools.
• Subarea — the actual navigation items users click. Each subarea points to a destination: a table's main page (showing default view), a specific view, a dashboard, a URL, a custom page, a web resource.

The maker designs the area / group / subarea structure to match how users think about the app.

Design principles.

• Mirror the work, not the data model. Group by what users do, not by the tables underneath. My Work (combining Activities, Tasks, Appointments) is more user-friendly than separate menu items per Dataverse table.
• Limit depth — three levels (area / group / subarea) is enough. Don't over-nest.
• Frequency-ordered — most-used items at the top of each group.
• Verb-noun phrasing — My Open Opportunities beats Opportunities (Mine).
• Icon consistency — use the platform icon library; bespoke icons can be uploaded but rarely worth the maintenance burden.
• Avoid orphan tables — every important table should be reachable from the navigation without searching.

Role-based visibility. Sitemap items can be visible only to specific security roles:

• Managers see Forecast and Team Performance.
• Sellers don't see Settings or Administration.
• Service agents don't see Sales-specific tabs.

Configured per subarea; the platform respects the user's roles automatically.

Customising the standard Dynamics 365 sitemaps. Sales Hub, Customer Service Hub, Field Service all ship with predefined sitemaps. Customisation typically:

• Adds custom tables to relevant groups.
• Hides Microsoft's defaults that aren't in use.
• Reorders items to match the customer's process.
• Adds external links (intranet pages, knowledge base URLs).
• Adds dashboards that match the customer's KPI structure.

Multi-app sitemaps. Different apps in the same environment have different sitemaps. The Sales app's site map has Sales tables; the Service app's has Service tables. Same Dataverse, different navigations per persona.

The modern site map designer. Microsoft has been migrating from the older site map designer (in the classic UI) to the modern designer in the Power Apps maker portal. The modern designer offers:

• Drag-and-drop reordering.
• Visual preview.
• Inline editing of labels, icons, destinations.
• Role-based visibility configuration.
• Validation against the current solution.

Older XML-based customisations remain supported but new work should use the modern designer.

Mobile rendering. The site map renders on Power Apps mobile differently — typically as a hamburger menu with the same hierarchy. Areas appear as top-level navigation; groups and subareas inside. Test on mobile during design — a beautiful desktop site map can be unusable on mobile.

Customised landing experience. Beyond the site map, the app's landing experience can be tuned:

• Default landing area / subarea — the page users see when they open the app.
• Personalised home dashboard — combining cues, charts, and shortcuts.

Configured per app or per profile.

Common patterns.

• My Work as the top group with Activities, Open Records, Recent — the "today" view.
• Customers group with Accounts, Contacts.
• Sales / Service group with Leads, Opportunities, Quotes / Cases, Knowledge.
• Reports & Dashboards group at the bottom.
• Admin / Settings area restricted to admin roles.

Common pitfalls.

• Too many items per group — 15 subareas per group is unusable; split into multiple groups.
• Wrong default landing — users open the app to an irrelevant page and immediately have to click elsewhere. Set sensibly.
• Bottom-of-menu critical items — important items below the fold get ignored. Surface them higher.
• Stale references — site map links to deleted dashboards or removed tables produce broken navigation.

Operational discipline. Treat the site map as UX investment. Iterate based on user feedback; A/B test if changes are substantial. The site map is the daily face of the app.