PL-900 Objective 3.3: Build a Model-Driven App

Model-Driven App Development Overview

Building model-driven apps represents a fundamentally different development approach compared to canvas apps, focusing on data structure and business logic rather than pixel-perfect interface design. Makers define which Dataverse tables the application manages, configure forms displaying record details, create views presenting filtered lists, and organize navigation through sitemaps. The Power Platform generates responsive user interfaces automatically based on these metadata configurations, ensuring consistent design language and behavior without manual screen design. This approach accelerates development for data-centric business applications while maintaining professional appearance and accessibility standards automatically.

The model-driven methodology particularly benefits scenarios with complex data relationships, extensive business logic, and sophisticated security requirements. Applications automatically respect Dataverse relationships, enabling intuitive navigation between related records through subgrids and lookups. Business rules, workflows, and plugins execute consistently regardless of how users access data. Security roles defined in Dataverse control which records users can view, create, modify, or delete without custom permission code in applications. These integrated capabilities make model-driven apps powerful tools for comprehensive business applications managing significant data complexity.

Creating Model-Driven Apps from Tables

Prerequisites and Environment Requirements

Model-driven app creation requires a Dataverse environment containing the tables the application will manage. Unlike canvas apps that connect to diverse data sources, model-driven apps exclusively use Dataverse, leveraging its relationship capabilities, security model, and business logic infrastructure. Organizations typically use existing standard tables from the Common Data Model for common business entities or create custom tables for specialized requirements. Makers need Environment Maker or System Administrator roles providing permissions to create apps and access tables within environments.

Proper table design precedes app creation, with well-structured tables including appropriate columns, relationships to other tables, business rules enforcing data quality, and security roles controlling access. Tables should represent clear business entities like customers, orders, projects, or cases with logical column types and relationship patterns. Model-driven apps surface these table definitions through generated interfaces, so table structure directly impacts user experience. Investing time in thoughtful table design before app creation ensures intuitive, functional applications without extensive customization requirements.

Using the App Designer

The model-driven app designer provides a visual interface for configuring which tables participate in applications, which forms and views are available, and how navigation organizes access to app functionality. Makers start by creating new model-driven apps through the Power Apps maker portal, choosing blank templates or starting from existing solutions. The designer presents pages representing different aspects of configuration including table selection, form and view assignments, and sitemap organization. Changes preview in real-time, showing how configurations affect user experience without requiring app publication for every modification.

Adding tables to apps happens through table selection interfaces where makers browse available Dataverse tables, selecting those relevant to the app's purpose. The designer automatically includes default main forms and system views for selected tables, providing functional starting points that makers customize as needed. Tables can be added to multiple apps, with each app potentially configuring different forms, views, or navigation for the same underlying tables. This flexibility enables specialized apps for different departments or workflows while maintaining consistent underlying data structures.

Configuring the Sitemap

Sitemaps define app navigation structure, organizing tables, dashboards, and other components into logical hierarchies that users navigate through app menus. The sitemap designer uses a three-level hierarchy: areas represent major functional sections appearing as top-level navigation tabs, groups organize related items within areas, and subitems represent individual tables, views, or dashboards users access. A Sales area might contain Customers and Opportunities groups, with each group listing relevant tables and views as subitems providing direct access to specific data perspectives.

Effective sitemap design groups related functionality together, making apps intuitive without extensive training. Common patterns include organizing by business process stages (lead management, opportunity management, quote management), by entity type (people, transactions, documents), or by user role (sales, service, management). Navigation labels use business terminology rather than technical table names, helping users understand purposes without knowing database structures. Sitemaps can include external URLs launching related systems or documentation, integrating model-driven apps into broader application ecosystems.

Modifying Forms

Form Types and Selection

Model-driven apps use several specialized form types serving distinct purposes in the user experience. Main forms provide comprehensive record views containing all relevant fields, related record subgrids, and business process flows, used for detailed record viewing and editing. Quick Create forms enable rapid record creation through lightweight dialogs containing essential fields only, appearing in contexts where users need to create related records without full navigation. Quick View forms display read-only information about related records in pop-ups or embedded on parent forms, providing context without leaving current screens. Card forms present summarized record information in compact layouts for reference scenarios.

Tables can have multiple main forms serving different user roles or process stages. Form order configuration determines which form displays by default when users open records, while security roles can restrict which users see specific forms. Users with access to multiple forms switch between them through form selector dropdowns, choosing layouts best matching their current needs. This multi-form capability enables role-specific experiences showing only relevant fields and related data for each user type without requiring separate applications or complex conditional visibility logic.

Using the Form Designer

The form designer provides a visual interface for customizing how record data displays, with makers dragging fields from field explorers onto form sections, repositioning elements, and configuring properties through property panes. Forms organize into tabs (major sections users navigate between), sections (logical groupings within tabs), and columns (side-by-side field arrangement). This hierarchical structure helps organize large amounts of information comprehensibly, preventing single-screen information overload through logical categorization and progressive disclosure.

Field configuration includes setting labels (display names different from technical column names), marking fields required or optional, making fields read-only to prevent modification, setting default values accelerating data entry, and defining visibility rules showing or hiding fields based on other field values. These configurations happen through visual interfaces without coding, enabling business analysts to implement sophisticated behaviors. Form designers also add components like subgrids displaying related records, timelines showing activity history, quick view controls surfacing related record information, and web resources embedding custom functionality.

Form Customization Capabilities

Creating and Modifying Views

View Types and Purposes

Views serve as saved queries presenting filtered, sorted lists of table records throughout model-driven apps. System views are defined by Microsoft or system administrators, available to all users and appearing in standard navigation. Public views are created by makers, shared organization-wide but allowing users to create personal copies for individual customization. Personal views enable individual users to save custom queries for frequently accessed data subsets without administrator involvement. Each view type serves different needs, with system views providing baseline perspectives, public views standardizing common organizational queries, and personal views supporting individual work patterns.

Views appear throughout applications in multiple contexts: as main lists users navigate from sitemap items, in lookup dialogs when users select related records, as subgrid contents displaying related data on forms, and in chart underlying data sources. This pervasive use makes view design critical to overall user experience, with well-designed views enabling efficient data discovery and poor views forcing users to scroll through irrelevant records or repeatedly apply same filters. Understanding where and how views appear helps makers create appropriate perspectives for each use case.

View Configuration Elements

View design involves multiple configuration elements working together to present appropriate data subsets. Column selection determines which table fields appear in the list, with makers balancing information density against readability. Too few columns force users to open records frequently to see basic information, while too many columns create wide, hard-to-scan lists. Sort order establishes default record sequencing, typically ordering by modification date, name, priority, or other relevant fields. Primary sort columns can have secondary sorts as tiebreakers, ensuring predictable ordering.

Filter criteria restrict which records appear in views, implementing queries that match specific conditions. Active records views filter out inactive or deleted records. My Records views show only records owned by current users. High Priority views display records marked with urgent flags. Date-based filters show records created this week, modified today, or due in the next 30 days. Complex filters combine multiple conditions using AND/OR logic, creating sophisticated queries matching precise business scenarios. Filter visibility can be user-editable, allowing filtering within predetermined parameters, or fixed, showing only specified record sets.

Using the View Designer

The view designer provides visual interfaces for configuring view columns, sorts, and filters without writing SQL queries or understanding database syntax. Makers select columns from field lists, seeing immediate previews of how views appear to users. Column properties include width (fixed or flexible), display names (overriding default labels), and custom formatting options. Column order establishes left-to-right sequence, with most important information typically leftmost since users scan lists that direction naturally.

Advanced view capabilities include grouping records by field values (grouping cases by status or priority), calculated columns showing values derived from other fields, and custom controls altering how specific fields display (showing progress bars for percentages or icons for statuses). View access can be controlled through security roles, with different users seeing different default views based on permissions. Views also connect to charts, with chart data coming from underlying view queries, enabling consistent filtering between visualizations and underlying record lists.

Sharing Model-Driven Apps

Security Model Integration

Model-driven app sharing integrates tightly with Dataverse security roles, requiring users to have both app access and appropriate table permissions. Unlike canvas apps where sharing grants app usage rights directly, model-driven apps check security role assignments determining what users can do with app tables. This dual-layer approach ensures users can only access data they're authorized to see and perform only actions their roles permit, maintaining organizational security policies automatically without custom permission code in applications.

Security roles define privileges for tables including read (view records), write (modify records), create (add new records), delete (remove records), append (associate related records), and assign (change record ownership). These privileges have scope levels: user (only own records), business unit (records in user's BU), parent/child business units (hierarchical access), or organization (all records). This granular control enables sophisticated permission models matching organizational structures, with sales representatives accessing their own accounts while managers access their team's accounts and executives accessing all accounts.

App Sharing Process

Sharing model-driven apps begins in the Power Apps maker portal where makers select apps and choose share options. Unlike canvas app sharing that specifies user or co-owner permissions, model-driven app sharing assigns users to security roles providing necessary table access. Makers add users or Azure AD security groups, selecting appropriate security roles that grant required permissions. The sharing interface validates that selected roles provide app access and sufficient table permissions, warning if users might not see expected functionality due to role limitations.

Recommended practice involves creating custom security roles specifically for applications rather than using default system roles. Custom roles include exact privileges needed for app functionality without excessive permissions that violate least-privilege principles. For a customer service app, roles might include Service Agent (read/write cases, read accounts and contacts), Service Manager (all agent privileges plus case assignment and deletion), and Service Administrator (full access including app customization). This role-based approach scales better than individual user permissions, with new employees automatically receiving appropriate access through role assignment.

App Publication and Distribution

Published model-driven apps appear in users' Power Apps mobile app and web portal automatically based on security role assignments. Unlike canvas apps requiring explicit sharing with each user, model-driven apps become available to anyone with roles granting app access permissions. This automatic discovery ensures users find apps relevant to their roles without manual distribution or communication about app availability. Apps can also embed into SharePoint pages or Teams channels, integrating into existing workflows.

App URLs provide direct links enabling bookmarks or shortcuts bypassing Power Apps portal navigation. These persistent links remain stable across app updates, ensuring bookmarks continue working as apps evolve. Organizations distribute app URLs through intranet portals, email communications, or Teams messages, guiding users to relevant applications. Deep linking can open specific records or views directly, enabling communications that link to particular data contexts like "review this high-priority case" or "approve this pending order."

Real-World Model-Driven App Scenarios

Scenario 1: Customer Service Case Management

Scenario 2: Project and Task Tracking

Scenario 3: Sales Opportunity Management

Best Practices for Model-Driven App Development

Table Design Considerations

• Start with data model: Design tables, relationships, and business rules before creating apps to ensure solid foundation
• Use standard tables: Leverage Common Data Model tables when they fit requirements for proven designs and Dynamics 365 compatibility
• Create custom tables thoughtfully: Only create custom tables for genuinely unique entities not covered by standard tables
• Establish naming conventions: Use consistent, business-friendly names for tables and columns that users recognize
• Document customizations: Maintain clear documentation of custom tables, fields, and business rules for maintenance and knowledge transfer

Form Design Principles

• Prioritize essential information: Place most important fields at top of forms where users see them immediately without scrolling
• Group related fields: Use sections and tabs to organize information logically by topic or workflow stage
• Minimize required fields: Only make fields required when truly necessary, avoiding frustration from prevented form saves
• Include helpful labels: Use clear, descriptive field labels and add descriptions providing context for complex fields
• Test with actual users: Validate forms with people who will use them daily, incorporating feedback before deployment

View Design Guidelines

• Create task-focused views: Design views matching how users actually work rather than exposing all possible fields
• Balance column count: Show enough information for decision-making without overwhelming wide, crowded lists
• Apply sensible defaults: Set default views and sorts matching most common usage patterns
• Enable personal views: Allow users to create personal views for individual work patterns beyond standard views
• Review and refine: Regularly review view usage analytics and user feedback, refining views based on actual behavior

Exam Preparation Tips

Key Concepts to Master

• Dataverse requirement: Model-driven apps require Dataverse tables; they cannot use other data sources
• Automatic interface generation: Forms and views generate interfaces automatically from metadata configuration
• Form types: Understand main, quick create, quick view, and card forms serve different purposes
• View purposes: Views filter and display record lists throughout apps in navigation, lookups, and subgrids
• Sitemap structure: Navigation organizes through areas, groups, and subitems hierarchically
• Security role sharing: Sharing requires assigning security roles providing table access, not just app permissions

Practice Questions

Hands-On Practice Lab

Lab Activities

Lab Outcomes

After completing this lab, you'll have practical experience building model-driven apps from tables, customizing forms with fields and business rules, creating views with filters and columns, and sharing apps with security roles. This hands-on knowledge demonstrates core model-driven app development capabilities tested in the PL-900 exam and prepares you for building data-centric business applications.

Frequently Asked Questions