Model-Driven App Navigation (Sitemap)

Analogy categoryAnalogies

Sitemap Structure: Areas, Groups, and Subareas

The Sitemap is the navigation blueprint for a Model-Driven App, organized in three tiers: Areas appear in the left-hand app switcher-style navigation (like Sales or Service), Groups create labeled sections within an area, and Subareas are the actual clickable links to a table's views, a dashboard, or an embedded web resource. The Sitemap Designer provides a drag-and-drop, WYSIWYG canvas for arranging this hierarchy without editing raw XML directly, though the underlying definition is still stored as a SiteMap XML component.

🏏

Cricket analogy: A cricket stadium's signage hierarchy has top-level zones (Areas) like 'Pavilion' and 'General Stand', sections within each zone (Groups) like 'Members Only', and individual gate numbers (Subareas) that lead to actual seats.

Configuring Subareas: Tables, Dashboards, and URLs

A Subarea most commonly links to a table, and you choose which default view opens (typically the active records view) and which icon represents it. Subareas can also point to a specific Dashboard, an HTML web resource for a custom landing page, or even an external URL. Each Subarea can be restricted to specific security roles under its Privileges settings, so users without adequate access simply never see that navigation link rather than seeing an access-denied error after clicking it.

🏏

Cricket analogy: Restricting a Subarea by security role is like a stadium's VIP corporate box entrance being invisible on the general-admission wayfinding map, so ordinary ticket holders never even see a sign pointing toward it.

Multiple Apps and Shared Tables

A single Dataverse environment often hosts several Model-Driven Apps (for example, separate Sales and Service apps), each with its own Sitemap, even though they share the same underlying tables. This lets you expose the Account table with a sales-focused view and command bar in one app and a support-focused view in another, without duplicating the table itself — the App Designer lets you assemble which tables, dashboards, and business process flows belong to each app's Sitemap independently.

🏏

Cricket analogy: The same player database powers both a broadcaster's fan-facing stats app and a team's internal analytics app, each presenting the shared data differently, just as one Account table serves multiple Model-Driven Apps.

xml

<SiteMap>
  <Area Id="Sales" Title="Sales" Icon="salesicon">
    <Group Id="CustomerGroup" Title="Customers">
      <SubArea Id="accounts" Entity="account" Title="Accounts" />
      <SubArea Id="contacts" Entity="contact" Title="Contacts" />
    </Group>
    <Group Id="PipelineGroup" Title="Pipeline">
      <SubArea Id="opportunities" Entity="opportunity" Title="Opportunities" />
      <SubArea Id="salesDashboard" Dashboard="{sales-dashboard-guid}" Title="Sales Dashboard" />
    </Group>
  </Area>
</SiteMap>

The modern Sitemap Designer opens directly from the App Designer's command bar, and changes are only visible to users after you publish the app — always click Save and Publish, then refresh a test browser tab, before assuming a navigation change has gone live.

Restricting a Subarea to a specific security role hides it from the navigation, but it does not remove the user's ability to reach that table's records through a different path, such as a lookup, an advanced find, or a related subgrid — Sitemap restrictions control discoverability, not actual data security, which must still be enforced through security roles.

The Sitemap defines a three-tier navigation hierarchy: Areas, Groups, and Subareas.
Subareas most commonly link to a table's default view but can also point to a Dashboard, web resource, or external URL.
The Sitemap Designer provides a drag-and-drop canvas, though the definition is stored as SiteMap XML underneath.
Subareas can be restricted to specific security roles so users without access never see the navigation link at all.
One Dataverse environment can host multiple Model-Driven Apps, each with an independent Sitemap over shared tables.
Navigation changes require Save and Publish before they appear for end users.
Hiding a Subarea from navigation is a discoverability control, not a substitute for proper security role restrictions on the underlying table.