4.1 Model-Driven App Design, Site Map Navigation & Modern App Designer

4.1 Model-Driven App Design, Site Map Navigation & Modern App Designer

In the Microsoft Power Platform ecosystem, Model-Driven Applications represent the enterprise standard for data-dense, process-centric business solutions. Unlike Canvas Apps—which start from a blank visual canvas and require makers to manually bind controls, write expressions, and design responsive layouts—Model-Driven Apps are data-first and component-driven. The user interface is dynamically rendered by the Unified Interface framework based entirely on the underlying Microsoft Dataverse schema, forms, views, business processes, and security architecture.

For a Power Platform Functional Consultant preparing for the PL-200 certification, mastering the Modern App Designer, understanding the mechanics of Site Map navigation hierarchies, configuring subarea content types, and implementing robust role-based app security are core competencies.

---

1. The Model-Driven Component Paradigm & Modern App Designer

Model-driven app development separates data architecture and business logic from visual presentation. When you build a model-driven app, you assemble modular components into a cohesive solution. The Unified Interface automatically handles responsive rendering across desktop displays, tablets, and mobile devices without custom CSS or viewport media queries.

+-----------------------------------------------------------------------------------+
|                 MODEL-DRIVEN APP COMPONENT-DRIVEN ARCHITECTURE                    |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | 1. DATA LAYER (Dataverse Engine)                                            |  |
|  |    - Standard & Custom Tables (Entities)                                    |  |
|  |    - Columns (Attributes), Data Types, Choices & Formulas                   |  |
|  |    - Relationships (1:N, N:1, N:N) & Cascading Rules                        |  |
|  +-----------------------------------------------------------------------------+  |
|  | 2. UI & NAVIGATION LAYER (Unified Interface)                                 |  |
|  |    - Model-Driven Apps (`appmodule`) & App-Level Security Roles              |  |
|  |    - Navigation Site Map: Area -> Group -> Subarea                          |  |
|  |    - Forms (Main, Quick Create, Quick View, Card) & Views (Public, System)   |  |
|  |    - Dashboards, Power BI Embeds & Custom Pages                             |  |
|  +-----------------------------------------------------------------------------+  |
|  | 3. LOGIC & AUTOMATION LAYER                                                 |  |
|  |    - Business Process Flows (BPFs) & Task Flows                             |  |
|  |    - Business Rules (Client-Side & Server-Side Validation)                  |  |
|  |    - Automated & Instant Power Automate Cloud Flows                         |  |
|  |    - Classic Workflows & Custom Dataverse Plugins                           |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

Modern App Designer vs. Classic App Designer

Historically, model-driven apps were authored using the Classic Solution Explorer and Classic App Designer. Microsoft has superseded this with the Modern App Designer inside the Power Apps Maker Portal (make.powerapps.com).

[!NOTE] The Modern App Designer introduces Custom Pages, which bridge the gap between Model-Driven and Canvas apps. Custom Pages bring the pixel-perfect flexibility and custom connectors of Canvas apps directly into model-driven navigation panes, dialogs, or full-page views.

---

2. Navigation Architecture: The Area -> Group -> Subarea Hierarchy

The backbone of every model-driven app is its Site Map. The site map defines the navigation pane displayed on the left side of the Unified Interface. Dataverse enforces a strict three-level hierarchical structure for site maps:

+-----------------------------------------------------------------------------------+
|                         SITE MAP HIERARCHICAL TOPOLOGY                            |
|                                                                                   |
|   [AREA: Sales] (Top-Level Functional Domain Switcher)                           |
|      |                                                                            |
|      +---> [GROUP: My Work] (Collapsible Visual Section Heading)                   |
|      |        |                                                                   |
|      |        +---> [SUBAREA: Dashboards]  (Content Type: Dashboard)              |
|      |        +---> [SUBAREA: Activities]  (Content Type: Table -> Activity)      |
|      |                                                                            |
|      +---> [GROUP: Customers] (Collapsible Visual Section Heading)                |
|      |        |                                                                   |
|      |        +---> [SUBAREA: Accounts]    (Content Type: Table -> Account)       |
|      |        +---> [SUBAREA: Contacts]    (Content Type: Table -> Contact)       |
|                                                                                   |
|   [AREA: Settings] (Secondary Functional Domain Switcher)                         |
|      |                                                                            |
|      +---> [GROUP: Configuration]                                                 |
|               +---> [SUBAREA: Product Catalog] (Content Type: Table -> Product)   |
|               +---> [SUBAREA: Training Portal] (Content Type: URL -> External)    |
+-----------------------------------------------------------------------------------+

The Three Hierarchical Levels

1. Area (<Area>):

   • The top-level functional domain container. Areas partition large enterprise applications into distinct operational zones (such as Sales, Service, Marketing, or Administration).
   • Display Behavior: In the Unified Interface, when an app contains two or more Areas, Dataverse renders an Area Switcher dropdown at the bottom of the left navigation pane. If an app contains only one Area, the area switcher is automatically suppressed to conserve screen space.
   • Properties: ID, Title (localized display string), Icon, and Security Role / SKU privileges.

2. Group (<Group>):

   • A logical category header within an Area that organizes related subareas. For example, within the Sales Area, you might define Groups named My Work, Customers, and Collateral.
   • Display Behavior: Groups render as non-clickable bold section headings in the navigation rail. Users can expand or collapse groups to manage screen clutter.
   • Properties: ID, Title, and localized display names.

3. Subarea (<SubArea>):

   • The actionable, clickable leaf node within a Group. Clicking a Subarea navigates the user to a specific record grid, dashboard, external URL, or custom component in the primary application viewport.
   • Properties: ID, Content Type, Target Entity/Dashboard/URL/Resource, Icon, Title, Default Vector Icon, and Client availability flags.

---

3. Subarea Content Types & Configuration Properties

When configuring a Subarea in the Modern App Designer, you must select one of four fundamental Content Types:

+-----------------------------------------------------------------------------------+
|                         SUBAREA CONTENT TYPES MATRIX                              |
|                                                                                   |
|   1. TABLE (Entity)        2. DASHBOARD             3. URL              4. WEB RESOURCE   |
|   +-----------------+      +-----------------+      +-----------------+ +-----------------+|
|   | Account         |      | Sales Hub Dash  |      | https://corp... | | custom_view.html||
|   | Contact         |      | Power BI Embed  |      | SharePoint Lib  | | React Web Control||
|   | Opportunity     |      | Tier 1 Service  |      | Help Wiki Portal| | Silverlight/SVG ||
|   +-----------------+      +-----------------+      +-----------------+ +-----------------+|
|   Loads Entity Grid        Loads Interactive        Loads External     Loads Solution-aware|
|   & Entity Forms           Data Visualizations      Webpage / Intranet Custom HTML/JS code|
+-----------------------------------------------------------------------------------+

In-Depth Content Type Comparison

Advanced Subarea Configuration Options

• Client Availability: You can configure whether a subarea is accessible on Web (Browser), Outlook (Dynamics 365 App for Outlook), and Mobile (Power Apps Mobile Client).
• Check Privileges (Security Trimming): By default, Dataverse applies automatic security trimming. If a subarea points to a Table for which the logged-in user has zero Read permissions, Dataverse automatically hides that subarea from the navigation pane.
• Explicit Parameter Passing: For URL and Web Resource subareas, you can enable "Pass record object-type code and unique identifier as parameters" to transmit runtime context.

---

4. App Access Security, Role Assignment & Sharing Mechanics

Deploying a model-driven application into an enterprise environment requires a clear understanding of the Two-Tier Security Model. Access to a model-driven app is governed by two separate authorization layers:

+-----------------------------------------------------------------------------------+
|                 TWO-TIER MODEL-DRIVEN APP SECURITY EVALUATION                     |
|                                                                                   |
|   USER ATTEMPTS ACCESS: https://org.crm.dynamics.com/main.aspx?appid=abc-123      |
|                                                                                   |
|   [TIER 1: APP MODULE ACCESS] ------------------------------------------------+   |
|   Does the user's Security Role grant access to this specific Model-Driven App?|   |
|        |                                                                      |   |
|        +---> NO  ===> [HTTP 403 / Access Denied: App Not Assigned]           |   |
|        |                                                                      |   |
|        +---> YES ===> Proceed to Tier 2 Evaluation                            |   |
|                                                                               |   |
|   [TIER 2: DATAVERSE DATA PRIVILEGES] ----------------------------------------+   |
|   Does the user hold Read/Write privileges for the tables in the Site Map?    |   |
|        |                                                                      |   |
|        +---> NO  ===> Navigation Subareas trimmed / Data fields hidden        |   |
|        |                                                                      |   |
|        +---> YES ===> Full access to entity grids, forms, and command bars    |   |
+-----------------------------------------------------------------------------------+

Tier 1: App Module Privilege & Role Assignment

• In Dataverse, every model-driven app is cataloged as a record in the App Module (appmodule) system table.
• To open an app, a user must hold at least one Security Role that has been explicitly assigned to the app in the App Sharing panel or Power Platform Admin Center.
• System Administrators and System Customizers have access to all model-driven apps by default.
• If a user has valid table privileges across the database but is not assigned an app's security role, the app tile will not appear in their Office 365 app launcher or Power Apps portal, and direct URL access will fail with an authorization error.

Tier 2: Underlying Dataverse Table Privileges

• App role assignment grants access only to the shell and navigation container of the application.
• It does not grant automatic data permissions. If User A has access to the "Sales App" (Tier 1) but their assigned Security Role has Read = None on the Opportunity table, Dataverse security will either hide the Opportunity subarea entirely or display an "Insufficient Permissions" banner upon navigation.

URL-Based App Sharing & Distribution

Model-driven apps can be shared directly using their unique web address. The Unified Interface uses a deterministic URL structure:

$\text{App URL} = \text{https://}\langle\text{environment-name}\rangle\text{.crm.dynamics.com/main.aspx?appid=}\langle\text{app-guid}\rangle$

• Unique App Name / URL Suffix: Makers can define a human-friendly URL suffix (e.g., https://contoso.crm.dynamics.com/apps/fieldservice) in app properties to simplify bookmarking and corporate distribution.
• Direct Deep Linking: Functional consultants can construct deep links directly to specific forms, entity records, or views by appending parameters such as &pagetype=entityrecord&etn=account&id=<record-guid>.