7.1 Composing a Model-Driven App

A model-driven app is essentially a curated lens over Microsoft Dataverse: you decide which tables, dashboards, and pages appear, how the left-hand navigation is organized, and which forms and views each table exposes. The composition work all happens in the modern app designer at make.powerapps.com, and the AB-410 exam expects you to know that designer cold.

Creating the App and Adding Pages

From make.powerapps.com, select Apps in the left navigation, then New app > Model-driven. Give the app a name (and optionally a description and icon), and the designer opens with two working surfaces: the Pages pane on the left and the canvas/preview in the center.

Select Add page on the command bar and you get exactly five content types:

Exam trap: a canvas app cannot be added directly as a page. The supported pattern is to embed canvas functionality through a custom page, which uses the canvas designer but lives inside the model-driven app shell.

Navigation: Areas, Groups, and Subareas

The sitemap behind every model-driven app is a strict three-level hierarchy:

1. Areas — the top-level switches, usually shown at the bottom-left of the app (for example, "Sales" vs. "Service" in first-party Dynamics 365 apps)
2. Groups — collapsible headings within an area
3. Subareas — the individual clickable entries

In the modern designer, Microsoft renamed subareas to pages, and older documentation (and some exam questions) still uses the word subarea. To build navigation you select the ellipsis (...) next to Navigation in the Pages pane and choose New area or New group, then drag pages under them. Each area, group, and subarea has a Title and a system-generated ID, plus advanced settings for localized titles and descriptions so the navigation translates with the user's language. Most custom apps use a single area with several groups — you only add a second area when distinct personas need a fundamentally different navigation switch.

Dataverse Table Pages: Forms and Views

When you add a Dataverse table page, the designer asks whether to use a table already in the app or add an existing/new table from the environment. Re-adding an in-use table reuses the existing page; adding an existing table creates a fresh page bound to that table's components.

The exam-critical detail is the right-hand configuration pane for a table page. Under the table name you can expand Forms and Views and check exactly which of that table's forms and views this app exposes. Consequences:

• A table can have ten forms, but if you check only two, users of this app see only those two in the form selector.
• The same applies to views: unchecked views disappear from the view switcher in this app only — the table itself is untouched, and other apps are unaffected.
• This is app-level curation, not security. It reduces clutter; it does not stop a determined user from reaching data another way.

Save, Publish, and Play

Three command-bar actions control the app lifecycle, and the exam loves to blur them:

• Save — persists your edits so you can close and resume later. End users do not see saved-but-unpublished changes.
• Publish — makes the current state live for everyone who has access. Navigation changes, added pages, and form/view selections only reach users after publish.
• Play — opens the app in run mode in a new browser tab so you can test navigation and record flows. Play reflects the current saved state, which is ideal for validating before you publish.

Responsive Layout Across Devices

Model-driven apps render with the responsive Unified Interface: the same app adapts automatically to a desktop browser, a tablet, or the Power Apps mobile app on iOS and Android. Grids reflow into lists, multi-column forms stack into single columns, and the navigation collapses into a flyout menu. You do not design separate phone and tablet layouts — but you should still test in Play mode and on a phone, because very wide forms and dense dashboards can become awkward on small screens. Offline-capable tables can also be enabled for the mobile app, though that is configured separately in the app settings.

Maker scenario: you are building an "Event Operations" app. You create one area (default), three groups — Planning (Event and Venue table pages), Onsite (a custom page check-in screen and the Registration table), and Insights (an Operations dashboard plus a navigation link to a Power BI report). You trim the Event table page to one main form and two views, save, play-test on your phone, then publish. That whole workflow is what the blueprint means by "compose app."