Building and Sharing Model-Driven Apps | Guided by A Guide to Cloud

Building a model-driven app

Simple explanation

Building a model-driven app is like furnishing a house that is already built.

The house structure (walls, rooms, doors) comes from your data model — the tables and relationships you set up in Dataverse. You don’t draw the floor plan from scratch like you do with canvas apps.

Your job is to choose which rooms to include (which tables appear in the app), arrange the furniture in each room (customise forms), and decide what view people see when they walk in (configure views).

The modern app designer

Tom is building his property management app. Here is the process in the modern app designer:

Step 1 — Create the app. In make.powerapps.com, select “Model-driven app” and give it a name and description.

Step 2 — Add tables to the sitemap. The sitemap is the left navigation panel. Tom adds four tables: Properties, Tenants, Maintenance Requests, and Inspections. Each one becomes a navigation item.

Step 3 — Configure forms and views. For each table, Tom selects which form users see when they open a record and which view they see when browsing the list.

Step 4 — Preview and publish. Tom clicks Play to preview the app in the designer, then publishes to make it live.

What is the sitemap?

The sitemap defines the navigation structure of a model-driven app — the menu items in the left panel. You organise it into:

Areas — top-level sections (e.g., “Operations”, “Administration”)
Groups — categories within an area (e.g., “Property Management”, “Reports”)
Pages — individual items that link to table views, dashboards, or custom pages

Tom’s sitemap has one area called “Property Operations” with two groups: “Day to Day” (Properties, Tenants, Maintenance) and “Compliance” (Inspections).

Form types

Model-driven apps use several form types. Each serves a different purpose:

Form type	What it does	When it appears
Main form	Full record view with tabs, sections, and all fields	When you open a record
Quick Create form	Lightweight form for fast data entry	When you click the ”+” button to add a new record
Quick View form	Read-only snippet of a related record	Embedded inside another record’s main form
Card form	Compact view of a record	Used in some views and Outlook integrations

Customising the main form

Tom’s Property main form is organised into tabs and sections:

General tab

Property Details section: address, city, property type, bedrooms, rent
Status section: availability, last inspection date

Tenant tab

Current Tenant section: quick view form showing tenant name, contact, lease dates
Lease History section: sub-grid of past tenants

Maintenance tab

Open Requests: sub-grid filtered to show only open maintenance requests
Timeline: shows all activities — notes, emails, calls related to this property

Sub-grids: related records inside a form

A sub-grid is a mini-table embedded inside a form that shows related records. On Tom’s Property form, the “Open Requests” sub-grid shows all maintenance requests linked to that property.

Sub-grids are powerful because users see everything about a record in one place without navigating away. You configure which view the sub-grid uses and which columns to display.

Quick Create forms

When someone at Summit Realty needs to log a new maintenance request urgently, they don’t want to fill in a full form. The Quick Create form pops up as a small panel with just the essential fields:

Property (auto-filled if created from a property record)
Issue description
Priority
Reported by

They save it in seconds and fill in details later via the main form.

Views: different lenses on the same data

A view is a saved query that shows a filtered, sorted list of records with specific columns.

System views vs personal views

Type	Created by	Visible to	Example
System view	App maker or admin	Everyone using the app	”Active Properties”, “Overdue Maintenance”
Personal view	Individual user	Only that user	”My Properties in Auckland”

System views are built into the app. Personal views let users save their own filters without affecting anyone else.

Creating and modifying views

Tom created these system views for his Maintenance Requests table:

View name	Filter	Columns shown
All Active Requests	Status not equal to Closed	Property, Issue, Priority, Created On, Assigned To
High Priority	Priority equals Urgent or High	Property, Issue, Assigned To, Days Open
Unassigned Requests	Assigned To is empty	Property, Issue, Priority, Created On
My Requests	Assigned To equals current user	Property, Issue, Priority, Status

Each view is configured in the table designer: pick columns, set filters, choose sort order, and save. Views appear in the app’s view selector dropdown.

Exam tip: views are per-table, not per-app

Views are defined at the table level in Dataverse, not at the app level. This means if Tom creates a view for the Properties table, it can be used in any model-driven app that includes that table.

If a question asks where to create views, the answer is in the table designer in Dataverse (or from the app designer which opens the table designer).

Sharing model-driven apps works differently from canvas apps. Instead of sharing with individual users, you use Dataverse security roles.

How it works

Create or choose a security role — defines what tables a user can read, write, create, delete
Assign the security role to users — via the Power Platform admin centre or Entra groups
Share the app — assign the security role to the app so users with that role can access it

Tom created two security roles:

Role	Access level
Property Manager	Full access to all tables — create, read, update, delete
Maintenance Technician	Read-only for Properties and Tenants, full access to Maintenance Requests

Technicians can see property details and log maintenance updates, but they cannot edit property information or tenant records.

Two very different sharing models
Feature	Canvas App Sharing	Model-Driven App Sharing
How you share	Share directly with users or groups	Assign Dataverse security roles
Roles available	User or Co-owner	Custom security roles (granular)
Data access	Separate — users need connector permissions	Integrated — security roles control both app and data
Granularity	App-level only (run or edit)	Table-level, row-level, column-level
Best for	Simple sharing with small teams	Enterprise apps with role-based access
Managed via	Power Apps portal	Power Platform admin centre

Why security roles are powerful

Security roles in Dataverse offer granular control:

Table-level: Can this role see the Properties table at all?
Record-level: Can this role see all records, only their own, or only their team’s?
Column-level: Can this role see the rent amount column?

This means Tom can give technicians access to property addresses for navigation but hide financial details like rent and deposit amounts. All controlled by the security role, not the app.

🎬 Video walkthrough

🎬 Video coming soon

Building Model-Driven Apps — PL-900 Domain 3

~14 min