# Building Model-Driven Apps with Power Apps

> Chapter 8 of the Courseiva PL-900 curriculum — https://courseiva.com/learn/pl-900/power-apps-model-driven-apps

**Official objective:** 3.3 — Describe the capabilities of model-driven apps

## Introduction

For Exam PL-900 objective 3.3, you must describe the capabilities of model-driven apps. This concept matters because model-driven apps are the backbone of many enterprise business applications inside Microsoft Power Platform—they help organisations manage complex data like customer accounts, support cases, and project portfolios without needing a custom interface built from scratch. Understanding them is the difference between knowing how to build a simple survey and knowing how to build a system that a whole company runs on.

## The Personalised Filing Cabinet Analogy

Have you ever walked into a chaotic office where every document is just stacked on a desk, with no labels or folders to guide you? 

 That is the world of traditional spreadsheets and basic apps. Now, imagine that same office, but with a master architect who designs a custom filing system. This system has designated drawers for clients, a specific hanging folder for each project, and a colour-coded sub-folder for every invoice. The filing cabinet itself is not just a box—it is a system that forces you to fill in a date and a project code before you can drop a new invoice in its folder. This is a model-driven app. Unlike a canvas app, where you decide exactly where every button and text box sits on the screen (like arranging sticky notes on a whiteboard), a model-driven app starts with the data. You define your filing system first: the types of records (accounts, cases, invoices) and how they relate to each other. The Power Apps platform then automatically builds the user interface—the screen layouts, the search bar, the related-record views—based on that data model. You do not draw each button; you define the business rules, and the system draws the interface for you. This means every user in the office follows the same structured path to find or file a document, reducing errors and ensuring consistency. That is a model-driven app: a structured, data-first system that acts like a well-designed, personalised filing cabinet for your business processes.

## Core explanation

A model-driven app is a type of Power Apps application where the user interface (UI) is automatically generated from your data model and business logic. Think of it like this: you tell the system what data you have (e.g., 'Customer' records with a name, phone number, and order history) and what rules apply (e.g., 'when a new order is created, auto-assign it to a salesperson'), and the system builds the screens, navigation, and forms for you. You do not drag and drop buttons onto a blank canvas—the platform does the heavy lifting based on your data structure. 

 This is fundamentally different from a canvas app, where you design every pixel of the interface. Why does this exist? For complex business processes—like managing a sales pipeline, tracking IT support tickets, or processing insurance claims—you need consistency, security, and the ability to handle thousands of related records. Model-driven apps excel here because they are built on top of Dataverse, the underlying data platform that provides one central store for your business data. In a model-driven app, every piece of data is connected: a 'Contact' record is linked to an 'Account' record, which is linked to a 'Case' record. This relational structure means you can click on a customer's name from an order and instantly see all their support history, without manually creating lookups. 

 The key components of a model-driven app include: 

 - Tables: These are like the drawers in your filing cabinet. Each table stores a type of record, such as 'Account', 'Contact', or 'Invoice'. Tables have columns (fields) like 'Email' or 'Phone Number'. 
 - Views: These are pre-set filters and sorts for displaying records. For example, a 'My Active Accounts' view shows only the accounts assigned to the logged-in user that are not marked as inactive. 
 - Forms: These are the data entry screens. The system creates a main form for each table, but you can customise it by adding or removing fields, sections, and tabs. 
 - Charts and Dashboards: These provide visual summaries of your data, like a pie chart showing account distribution by industry. 
 - Business Rules: You can define rules that run on a form, like making a field required if a checkbox is ticked, without writing any code. 
 - Business Process Flows: These guide users through a step-by-step process, like 'Lead' to 'Opportunity' to 'Quote' to 'Order'. Each step shows only the relevant fields and buttons, reducing errors and speeding up work. 

 How does it work in practice? You start in the Power Apps maker portal by creating a solution (a container for your components). You define your tables in Dataverse, perhaps importing them from an existing database or creating them from scratch. You then create the app by selecting an existing Dataverse table as the main entity. The platform automatically generates a default set of forms and views. You can then customise these—adding fields, reordering sections, setting up a business process flow—and publish the app. Users access the app through a web browser, the Power Apps mobile app, or Microsoft Teams. All data is stored securely in Dataverse, with role-based security that controls who can read, create, update, or delete records. 

 Why would you use a model-driven app instead of a canvas app? For simple, free-form tasks like a single survey or a personal inventory tracker, a canvas app is quicker. But for enterprise-scale apps that need to manage complex relationships, enforce business rules, and serve hundreds of users with different roles, model-driven apps are the standard choice. They save huge amounts of development time because you are not designing a custom UI for every screen. You are designing the data model and rules, and the UI builds itself.

## Real-world context

An IT professional at a mid-sized logistics company is tasked with building an app to manage customer shipments and support tickets. They do not start by drawing a picture of a form. Instead, they first define the data structure in Dataverse. They create a table called 'Shipment' with columns for tracking number, origin, destination, weight, and delivery status. They also create a table called 'Support Case' with columns for subject, description, priority, and status. They relate these tables so that each shipment can have multiple support cases associated with it. 

 Next, they create a model-driven app by selecting the 'Shipment' table as the primary entity. The platform automatically generates: 

 - A main form for creating and editing shipments. 
 - A default view showing all shipments sorted by delivery date. 
 - A subgrid on the shipment form that automatically displays related support cases. 

 The IT professional then customises the form: they add a business rule that sets the priority to 'High' if the delivery date is past due, and they create a business process flow that forces users to confirm the package inspection before marking the shipment as 'Dispatched'. They also create a role-based security role so that only delivery drivers can update the status to 'Delivered', while customer service agents can only view and edit support cases. 

 Once published, the app is deployed to the company's logistics team. A customer service agent receives a phone call about a missing shipment. They open the model-driven app, search for the tracking number, and the system immediately shows the shipment record. In the same screen, they see a list of all previously logged support cases for that shipment. They click to create a new case, and a form appears that only shows the mandatory fields: subject, description, and contact name. The business process flow ensures they cannot save the case without assigning a priority. In the background, the system automatically links the new case to the shipment record and to the customer's account record. The agent then assigns the case to a dispatcher, who sees it on their personal dashboard. 

 The IT professional did not have to write a single line of code to build navigation between the shipment and case records, or to enforce the business rule. They simply defined the data structure and the rules, and the platform generated the rest. This is the core advantage: model-driven apps let IT professionals focus on business logic rather than interface design, making them ideal for complex, data-heavy enterprise scenarios.

## Exam focus

The PL-900 exam tests your understanding of what model-driven apps are, when to use them, and their key components—but not how to build one from scratch. You need to recognise the core concept: a model-driven app's UI is generated from the data model, not designed pixel by pixel. The exam loves to present scenario-based questions that ask: 'A company needs to manage customer accounts, orders, and support cases. Which type of app should they use?' The correct answer is almost always 'model-driven app' because it can handle related data, enforce business rules, and support role-based security. 

 The exam also focuses on the following specific components and terms. Be prepared to match definitions to these terms: 

 - Tables: The Dataverse storage structures for records. Know that a table is equivalent to a database table. 
 - Views: Pre-defined filters for displaying records. Common traps: confusing a view (a filter) with a form (a data entry screen). 
 - Forms: The screens for creating or editing records. The exam might ask which component is used to add validation logic without code—the answer is 'business rules' running on forms. 
 - Business Process Flows: Guided step-by-step processes. The exam tests that these are different from workflows (which run in the background) and from business rules (which apply to a single form). 
 - Dashboards and Charts: Visual summaries. Know that charts can be added to forms and dashboards. 
 - Role-based Security: Model-driven apps respect row-level security defined in Dataverse. The exam may ask: 'Which feature ensures a sales rep can only see their own accounts?' The answer is 'security role permissions on the Account table'. 

 Key traps to watch out for: 

 - The exam may try to trick you into thinking you build the UI manually for model-driven apps. Remember: the UI is generated from the data model—you only customise it, you do not build from a blank canvas. 
 - Do not confuse model-driven apps with automated workflows or Power Automate. A model-driven app is a user-facing application; Power Automate is for backend automation. 
 - The phrase 'low-code' appears frequently. Model-driven apps are considered low-code because you define data and rules rather than writing interface code. 
 - Questions might ask which platform (Dataverse) model-driven apps require. They must be built on Dataverse—they cannot use SharePoint or Excel as a data source (unlike canvas apps). 
 - Know the difference between 'canvas app' and 'model-driven app' by their defining characteristics: canvas = blank canvas, drag and drop; model-driven = data-model-first, UI generated. 

 You should memorise that model-driven apps are part of Power Apps, which is part of Microsoft Power Platform (alongside Power Automate, Power BI, and Power Virtual Agents). They are designed for enterprise-scale, role-based, data-centric applications. For PL-900, you only need to describe capabilities, not build them, so focus on the 'why' and 'what' rather than the 'how'.

## Step by step

1. **Create or Select a Dataverse Environment** — Before building any model-driven app, you need a Dataverse environment—a secure container for data. You either create a new one (if you have permissions) or use an existing one provided by your organisation. This step matters because all data for model-driven apps lives in Dataverse, so you must have a valid environment.
2. **Define Your Data Model (Tables and Columns)** — You decide what kinds of records your app will manage (e.g., Customer, Invoice, SupportTicket). In Dataverse, you create tables for each type, and then add columns to store specific data (e.g., CustomerName, InvoiceDate, TicketStatus). This is the most critical step because the rest of the app builds itself based on this structure.
3. **Relate Tables to Each Other** — You create relationships between tables, like linking a Customer to their Invoices or a SupportTicket to the Product it relates to. This enables the app to show related data together—for example, when viewing a Customer record, you can see all their Invoices in a subgrid. Without relationships, model-driven apps lose their main advantage.
4. **Customise Forms and Views** — The platform generates default forms (data entry screens) and views (pre-set filters). You then customise them: reorder fields, add sections, rename labels, or create new views like 'High Priority Tickets'. You also set up business rules (e.g., make a field required if a checkbox is checked) and business process flows (guided step sequences).
5. **Create and Configure the App** — In the Power Apps maker portal, you create a new model-driven app. You select one or more tables as the primary entities, choose which views and forms to include, and set the site map (navigation menu). You then publish the app, making it available to users via a URL, the Power Apps mobile app, or Microsoft Teams.
6. **Assign Security Roles and Deploy** — After publishing, you assign Dataverse security roles to users or groups. For example, 'Salesperson' can only read and update their own leads, while 'Sales Manager' can see all leads. You then share the app URL with your users. This final step ensures that each user sees only the data they are allowed to see.

## Comparisons

### Canvas App vs Model-Driven App

**Canvas App:**
- User interface is designed manually by dragging controls onto a blank canvas.
- Can connect to over 200 data sources including SharePoint, Excel, SQL, and Dataverse.
- Best for simple, task-specific apps like a single survey or a personal time tracker.

**Model-Driven App:**
- User interface is automatically generated from the data model and business logic.
- Can only connect to Dataverse as its data source.
- Best for complex enterprise apps that manage multiple related tables and enforce business rules.

### Business Rule vs Business Process Flow

**Business Rule:**
- Applies to a single form or field level—for example, making a field required when a checkbox is ticked.
- Runs in real time as the user fills in the form.
- Cannot guide the user through multiple stages or steps.

**Business Process Flow:**
- Guides the user through a multi-step process, such as Lead to Opportunity to Quote.
- Each step can show different fields, stages, and conditions.
- Enforces a structured workflow across multiple records.

### View vs Form

**View:**
- A pre-set filter and sort of table records, used for listing data.
- Cannot be used to create or edit records.
- Examples: 'My Open Cases', 'All Active Accounts'.

**Form:**
- A data entry screen used to create, read, update, or delete a single record.
- Contains fields arranged in sections and tabs.
- Can include business rules and subgrids to show related records.

## Diagram

_The flow from defining a data model in Dataverse to users accessing a fully functioning model-driven app with security._

```mermaid
flowchart TD
    A[Define Data Model in Dataverse] --> B[Create Tables and Columns]
    B --> C[Set up Table Relationships]
    C --> D[Platform Auto-generates Forms and Views]
    D --> E[Customise Forms, Views, Business Rules]
    E --> F[Create the Model-Driven App]
    F --> G[Assign Security Roles]
    G --> H[Users Access App via Browser or Mobile]
    H --> I[App Shows Data from Dataverse Based on Roles]
```

## Common misconceptions

- **Misconception:** Model-driven apps are just canvas apps with pre-made templates. **Reality:** Model-driven apps are fundamentally different: the entire UI is auto-generated from the data model and business logic, whereas canvas apps start from a blank canvas where you place each control manually. (Beginners often assume all Power Apps are the same, just with different starting points. The name 'model-driven' is not intuitive—it sounds like a template, not a different paradigm.)
- **Misconception:** You can use any data source with model-driven apps, just like canvas apps. **Reality:** Model-driven apps can only connect to Dataverse as their data source. They do not support direct connections to SharePoint, Excel, SQL Server, or other external connectors. (Because canvas apps are often taught first with a variety of data sources, people assume the same flexibility applies. The PL-900 exam explicitly tests this limitation.)
- **Misconception:** Model-driven apps do not allow any customisation of the user interface. **Reality:** You cannot completely redesign the layout from scratch, but you can heavily customise forms, views, and dashboards—adding fields, sections, tabs, and even custom CSS. The structure is rigid, but appearance and field placement are flexible. (New users hear 'auto-generated UI' and assume it is unchangeable. In reality, you have a lot of control within the defined structure.)
- **Misconception:** Model-driven apps can only display one table at a time. **Reality:** They are designed for relational data. A single form for an Account can display related Contacts, Cases, and Orders in subgrids. The app navigates between related tables seamlessly. (People who have only used flat spreadsheets or simple apps think one-screen-equals-one-table. Model-driven apps are built for complex, interconnected data.)
- **Misconception:** Security in model-driven apps is handled by the app itself. **Reality:** Security is handled at the Dataverse level through role-based security, not within the app. The app respects the permissions set in Dataverse, but you configure security there. (Beginners often think every app manages its own logins and permissions. The separation of app and data layer is not obvious until you work with Dataverse directly.)

## Key takeaways

- Model-driven apps generate their user interface automatically from the data model you define in Dataverse, unlike canvas apps that require manual drag-and-drop design.
- Model-driven apps require a Dataverse data source; they cannot connect directly to SharePoint, Excel, or other external databases.
- Key components of a model-driven app include Tables, Views, Forms, Dashboards, Business Rules, and Business Process Flows.
- Role-based security in model-driven apps is configured at the Dataverse table level, not within the app itself.
- Model-driven apps are ideal for complex, enterprise-scale business processes that involve multiple related tables and enforce strict business rules.
- Business Process Flows provide step-by-step guidance to users and can enforce data entry rules without any code.
- You cannot build a model-driven app from a blank canvas; you must start by defining your data structure in Dataverse.
- Charts and dashboards in model-driven apps provide visual summaries of your data and can be added to forms and personal dashboards.

## FAQ

**Can I use a model-driven app without Dataverse?**

No, model-driven apps are exclusively built on top of Dataverse. They cannot use direct connections to SharePoint, Excel, or other data sources like canvas apps can.

**Do I need to know any coding to build a model-driven app?**

For the basic capabilities tested in PL-900, no coding is required. You define tables, relationships, business rules, and forms using a visual interface. However, advanced features like web resources or JavaScript customisations may require code.

**What is the difference between a model-driven app and a canvas app?**

A model-driven app's user interface is generated from your data model and business logic, whereas a canvas app starts with a blank canvas where you drag and drop every control. Model-driven apps are data-first; canvas apps are design-first.

**How do users access a model-driven app?**

Users can access model-driven apps through a web browser, the Power Apps mobile app on smartphones or tablets, or embedded in Microsoft Teams. No separate installation is needed beyond the browser or mobile app.

**Can I add custom buttons or actions to a model-driven app?**

Yes, you can customise the ribbon to add custom buttons that call Power Automate flows, open other apps, or run JavaScript. However, the basic UI is still generated; you add custom elements on top of the defaults.

**Is a model-driven app the same as a 'Dynamics 365' app?**

Not exactly. Dynamics 365 apps (like Sales or Customer Service) are built on the same technology as model-driven apps—both use Dataverse and the model-driven architecture. But model-driven apps built with Power Apps are custom apps, while Dynamics 365 apps are pre-packaged business applications. The PL-900 exam focuses on custom model-driven apps.

## Check your understanding

1. **What is the primary data source required to build a model-driven app?**

   Answer: Dataverse. Model-driven apps cannot use other data sources like SharePoint or Excel directly.

2. **What is the main difference between a model-driven app and a canvas app regarding how the user interface is created?**

   Answer: In a model-driven app, the UI is automatically generated from the data model; in a canvas app, you design the UI by dragging and dropping controls onto a blank canvas.

3. **Name two key components of a model-driven app that control how users see and enter data.**

   Answer: Forms (for data entry) and Views (for listing records with pre-set filters).

4. **What component would you use to guide a user through a step-by-step business process, like converting a lead to an opportunity?**

   Answer: A Business Process Flow. It walks the user through stages and shows relevant fields for each step.

5. **How is security enforced in a model-driven app?**

   Answer: Through role-based security at the Dataverse level. Users are assigned security roles that determine what records they can read, create, update, or delete.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/pl-900/power-apps-model-driven-apps