What it does

The site map is the navigation definition for a model-driven app: a hierarchy of areas, groups and pages that becomes the left-hand nav at runtime. It's a solution component in its own right, associated with the app.

Key facts

• Three levels. Areas are the top switcher, shown in the lower left when an app has more than one. Groups are headings within an area. Pages — called subareas in the classic designer and in the underlying XML — are the clickable items.
• Page types: Dataverse table, dashboard, custom page, web resource, or navigation link (a URL, which opens in a new browser tab).
• Areas are disabled by default in the modern designer and enabled under Settings > Navigation > Enable Areas. Apps that already have multiple areas have it on and can't turn it off.
• A default site map is created automatically when the app is created, and can then be edited.
• IDs are auto-generated for areas, groups and pages. Microsoft's advice is to keep them — a non-unique ID causes runtime errors for users or import errors for makers.
• Site map titles and descriptions can be localised per language the environment supports, one title per language.
• In the classic site map designer, subareas carry a Privileges setting that shows or hides the subarea based on privileges in the user's security roles.
• Site map subarea URLs that link to an .aspx page aren't supported.
• The area icon applies to the deprecated web client site map, not the modern one.
• Deleting an area deletes its groups and pages; deleting a group deletes its pages.
• Editing site maps needs System Administrator or System Customizer, or the equivalent App, Customizations and Solution privileges.

When to use / skip

Every model-driven app has a site map, so the question is how much structure it needs. Groups within a single area is right for most apps — it keeps everything one click away and avoids the area switcher, which users genuinely don't find. Reach for multiple areas when the app serves distinct jobs that share tables, like a service desk app with a separate admin and configuration area. If you're contemplating five areas, you're probably contemplating more than one app.

Configuration decisions

• Areas or no areas — enable it and you've committed, and it changes how users navigate.
• Whether navigation mirrors the data model or the user's day. It should mirror the day; the data model is your problem, not theirs.
• Which pages get subarea privileges so they hide for users who can't use them, rather than showing and then erroring.
• Whether collapsible groups are on, which helps a long nav and hurts discoverability of anything below the fold.
• Whether Home, Recent and Pinned stay visible.
• Which languages get localised titles, and who supplies the translations.

Gotchas

• Hand-edited IDs that collide are a classic solution-import failure, and the error doesn't point at the site map.
• A page pointing at a table shows the views that are included in the app for that table. Forget to include the view and users get a page with the wrong default.
• Subarea privileges hide the link, they don't grant access. A user who bookmarks the record still hits Dataverse security — which is correct, but clients read hidden nav as a security control and it isn't one.
• The area switcher lives in the bottom left and is easy to miss. Users routinely report "the app is missing half the functionality" when it's just in another area.
• Navigation-link pages open in a new tab, which breaks the flow and, on mobile, can drop the user out of the app entirely.
• Site map changes need a publish, and the classic designer's behaviour around associating a new site map with an app is fiddly — it associates on the app's unique name if you close the browser first.

Consultant notes

• Design the navigation with the users, not with the client's process map. Half an hour of card sorting with three actual users beats a week of internal debate.
• Cap the number of pages per group at something a person can scan. Long nav lists are where features go to die unadopted.
• Set the naming convention up front and localise from the start if the client is multilingual. Retro-fitting translations across a large site map is a grim afternoon.
• Warn the client that changing navigation after go-live is a training event, not a config change. People learn the shape of the nav faster than they learn anything else in the app.

---

Worth revisiting if area behaviour changes, or if subarea privilege configuration moves into the modern designer.