A poorly structured site map makes even great apps unusable. Learn how to design navigation Areas, Groups, and Subareas from scratch — and wire them to security roles so each user sees exactly the menu they need, nothing more.
Imagine you've just finished building a solid model-driven app for your organization's field service team. The Dataverse tables are clean, the forms are well-designed, and the views filter data exactly the way users need. You publish the app — and the first feedback you get is: "I can't find anything. There are like thirty menu items and half of them have nothing to do with my job." Technicians are seeing the same configuration screens as billing managers. Finance staff are confused by dispatch queues. The app works, but nobody wants to use it.
This is a navigation problem, and the fix lives in the site map. The site map is the backbone of every model-driven app — it defines what appears in the left-hand navigation pane, how menu items are grouped, and which users see which options. Getting it right transforms a technically correct app into one that feels purpose-built for each person who opens it. Get it wrong, and even the best data model disappears behind a wall of irrelevant links.
By the end of this lesson, you'll understand how site maps are structured from the ground up, how to build multi-area navigation with logical groupings, and — critically — how to wire security roles into your menu design so different users see a navigation experience tailored to their actual job. We'll use a realistic field service scenario throughout, so every concept lands in context.
What you'll learn:
You should have a working model-driven app created in Power Apps (even a basic one is fine). If you've never built one before, start with Building Your First Model-Driven App: Site Map, Tables, Forms, and Views before continuing here. You'll also benefit from understanding how security roles work in Dataverse, which we'll touch on — see Dataverse Security: Business Units, Security Roles, and Teams for the full picture.
Before you touch a single setting, let's build a clear mental model of how site maps are structured. Think of it like a physical office building.
The building itself is your app. It has multiple floors — these are Areas. Each floor has several rooms — these are Groups. And inside each room are items of furniture — these are Subareas. When a user opens your app, they navigate between floors using a switcher at the bottom of the left nav panel, then browse the rooms and items on the floor they're on.
More precisely:
Here's what that looks like for our field service scenario:
Area: Field Operations
Group: Work Management
Subarea: Work Orders
Subarea: Service Appointments
Subarea: Technician Assignments
Group: Assets
Subarea: Customer Assets
Subarea: Products & Parts
Area: Administration
Group: Reference Data
Subarea: Service Types
Subarea: Territories
Subarea: Skills & Certifications
Group: User Management
Subarea: Teams
Subarea: Security Roles
A technician logging in sees Field Operations prominently, with their work-focused Subareas front and center. An admin sees Administration as their home. This clarity comes from deliberate structure, not accident.
Key insight
Areas are the strongest organizational boundary in a site map. Use them to represent fundamentally different job functions or departments. Groups within an Area should feel like natural clusters to someone doing that job — not alphabetical lists, not dumps of everything.
Microsoft has moved site map configuration into the modern app designer (as opposed to the older classic designer and standalone site map editor). Here's how to get there:
The modern designer gives you a visual tree on the left and a property panel on the right. As you click any navigation element, its properties appear on the right for editing. Changes are saved as part of the app, so you publish the app to push them to users.
Note
If your organization still uses the classic app designer, the concepts in this lesson are identical, but the UI differs. In the classic designer, you'd click the pencil icon on the Site Map tile to open the standalone site map editor. The hierarchy (Area → Group → Subarea) is the same either way.
An Area defines a top-level navigation context. Most apps need between one and four Areas. Fewer than one is impossible (you need at least one), and more than four starts to feel like you're asking users to navigate a department store.
To add an Area in the modern app designer:
area_field_operations.For our scenario, create two Areas: Field Operations and Administration.
Tip
Name Areas after the user who works in them, not the data they contain. "Field Operations" speaks to a technician. "Work Order Management System" does not. Your nav should feel like it was written by someone who does the job, not by someone who designed the database.
If you only have one Area, the area switcher at the bottom of the left nav doesn't appear — the single Area's content just shows directly. This is fine for simpler apps. Once you add a second Area, the switcher appears automatically.
Groups live inside Areas and act as visual organizers. They show up as bold headings in the left nav with their Subareas listed beneath. Users can't click a Group — it's a label, not a link.
To add a Group:
For the Field Operations Area, create two Groups: Work Management and Assets. For the Administration Area, create Reference Data and User Management.
The order of Groups within an Area determines their vertical order in the nav panel. You reorder them by dragging in the navigation tree. Put the most-used Group first — technicians should see Work Orders at the top of their nav, not buried under four other headings.
Warning
Don't create Groups with only one Subarea each just to add visual structure. A Group called "Work Orders" with a single Subarea "Work Orders" underneath it adds no value and wastes vertical space. Groups earn their keep when they contain two or more meaningfully related Subareas.
Subareas are where the navigation actually goes somewhere. Each Subarea has a Type that determines what it opens:
To add a Subarea:
Work Order, Service Appointment, Customer Asset, etc.For the Work Management group, add Subareas pointing to the Work Order, Service Appointment, and Technician Assignment tables. For Assets, add Customer Asset and Products & Parts.
Tip
Always set a Default View for table Subareas. Without it, users land on whatever view the system considers primary — which is often "Active [Table Name]," showing all records without any personalization. A technician opening "Work Orders" and seeing 3,000 unfiltered records is a usability disaster. Creating and Customizing Views in Model-Driven Apps: Filters, Sorting, and Editable Grids covers how to build those targeted views.
Here's where site map design gets genuinely powerful. In most enterprise apps, different users need to see different navigation. A technician has no business seeing the Security Roles configuration screen. A billing manager doesn't need the Dispatch Board. Showing everyone everything creates noise and, potentially, security risk.
Model-driven apps handle this through the intersection of site map visibility and security roles. The mechanism works like this:
Automatic role-based hiding (table Subareas):
This is the easiest mechanism and requires no extra configuration. If you create a Subarea pointing to the "Service Territory" table, and a technician's security role has no Read privilege on Service Territory, they simply won't see that Subarea. The platform evaluates the user's effective privileges and filters the nav accordingly.
This means your security role design and your site map design must work together. If you've structured model-driven app security roles correctly — technicians can read and update Work Orders but not Service Types, admins can configure everything — the nav will naturally surface only what each role needs.
Area-level role assignment (explicit control):
For Areas, you can go further. In the modern app designer:
Once you assign even one role to an Area, that Area becomes invisible to any user who doesn't hold at least one of those roles. This is an explicit allowlist. Use it for your Administration Area — assign it only to the "System Administrator" and "Field Service Manager" roles, and technicians will never see it in their nav.
Key insight
Role-based navigation has two layers: implicit (the platform hides Subareas when table privileges are absent) and explicit (you assign roles to Areas for hard visibility control). Use implicit hiding for table-level Subareas and explicit role assignment for entire Areas. This combination gives you fine-grained control without managing every Subarea individually.
Practical role structure for the field service scenario:
The Dataverse Fundamentals article explains the underlying table/row privilege model that makes this work.
Once your structure is in place, the final polish matters. Navigation that's technically correct but poorly ordered still frustrates users.
Reordering: In the modern app designer, drag Areas, Groups, and Subareas within the navigation tree to reorder them. The order in the designer matches what users see.
Naming conventions to follow:
Icons: The icon library in model-driven apps is limited to Microsoft's included set. Pick icons that are meaningful at a glance. A calendar icon for Appointments, a wrench for Work Orders, a person for Contacts. Don't assign the same icon to multiple Subareas — it defeats the purpose.
Avoid these naming anti-patterns:
Warning
Renaming a Subarea's Title does not rename the underlying table or view. It only changes the label that appears in the nav. This is a common source of confusion — a Subarea titled "Jobs" still points to the Work Order table, and users will see "Work Orders" in the view headers and form titles. Be consistent: if your organization calls them "Jobs," update the table display name as well, not just the Subarea label.
Changes to the site map don't reach users until you publish the app. In the modern app designer:
After publishing, test with each role profile:
Tip
Use your browser's private/incognito window to sign in as a test user while keeping your admin session active in the normal window. This lets you quickly compare what different roles experience without logging in and out repeatedly.
Set up a role-based site map for a project management app. Here's your scenario: you're building an app for a software consultancy. They have Project Managers, Developers, and Finance staff.
Step 1: Design your structure on paper first.
Sketch out:
Step 2: Build it in the app designer.
Step 3: Test the result.
Log in as a Developer. You should see Project Delivery with its two groups. Finance should be invisible. Log in as Finance Manager. Both Areas should appear in the switcher.
"My Subarea disappeared after publishing." The most common cause: the security role assigned to the test user has no Read privilege on the table that Subarea points to. The platform silently hides it. Fix: check the security role in Dataverse Security, grant at least Organization-level Read on the table.
"All users see the Administration Area even though I assigned it to Admin roles only." Check that you actually assigned roles to the Area (the explicit allowlist approach). If the Roles field on the Area is empty, all users see it. Assigning even one role flips it to allowlist mode.
"The Area switcher doesn't appear." You only have one Area defined. The switcher requires at least two Areas. Either add a second Area or understand that a single-Area app by design doesn't show the switcher.
"Users see a Subarea but get an error when they click it." They have nav visibility but no data privileges. This happens when a Subarea is visible because of an explicit URL type (not a table), or when you added role assignments to the Area but forgot to configure the underlying security role's table permissions. Nav visibility and data access are configured independently.
"I renamed a Subarea but users still see the old name." You didn't publish after saving. Always publish. And if they're using a cached session, have them do a hard refresh (Ctrl+Shift+R) or clear their browser cache.
The site map is your app's front door, and most users judge an app within the first thirty seconds of opening it. A well-structured site map — with meaningful Areas for different job functions, Groups that cluster related tasks, and Subareas that point to exactly the right views — turns a technically capable app into one people actually want to use.
The role-based layer takes this further. By combining Dataverse security role privileges (which automatically hide inaccessible table Subareas) with explicit role assignments on Areas (which hard-control entire navigation sections), you can give every user a nav experience that feels built for their specific job — without building multiple separate apps.
Here's what to build on next:
Navigation is the frame around your app. Get it right, and everything else inside it gets easier to use.