The sitemap is the left-hand navigation of a model-driven app — it defines what shows up, in what grouping, and in what order. It’s edited visually in the app designer’s Site Map designer, not written by hand.

Structure: areas, groups, subareas

  • Area — the top-level tab (e.g. “Sales,” “Service”), shown along the bottom of the nav in most layouts.
  • Group — a labeled section within an area (e.g. “My Work,” “Customers”).
  • Subarea — the actual clickable item: a table, a dashboard, or an external URL.

Controlling visibility by security role

Every subarea can be restricted to specific security roles, so different users see a different, simpler nav without needing separate apps. This is a common and effective way to reduce clutter: a frontline agent doesn’t need to see configuration-heavy areas a system administrator does, even within the same app.

One app, multiple experiences. Rather than building several near-identical apps for different roles, it’s usually better to build one app and use sitemap-level role visibility plus form-level role visibility to tailor the experience. Fewer apps to maintain, and changes only need to happen in one place.

Enabled apps vs. legacy sitemap

Modern model-driven apps use the App Designer, where the sitemap is just one component alongside the app’s table and dashboard selections. Each app can define its own sitemap, so the same table can appear differently (different grouping, different visible columns of functionality) across different apps in the same environment.