Overview
Forms are the primary data entry interface in Model-Driven Apps. Understanding form design, field configuration, and layout principles is essential for building intuitive, efficient user experiences in Power Platform solutions.
Prerequisites
- A Dataverse table already created with columns configured
- Maker permissions in a non-Default environment
- Basic understanding of Dataverse tables and columns
- Familiarity with Model-Driven Apps (helpful but not essential)
What is a Dataverse Form?
A Dataverse form is the visual interface users interact with to create, view, and edit records in Model-Driven Apps. Unlike Canvas Apps where you design every pixel, Model-Driven App forms are automatically generated from your table structure—but you control which fields appear, how they're organized, and what business logic applies.
Forms serve three primary purposes:
- Data entry – Capture new records with validation and required fields
- Data viewing – Display record details in a structured, scannable layout
- Data editing – Modify existing records with appropriate field-level security
Why forms matter:
- Forms are the first thing users see when opening a record—poor design frustrates users
- Well-organized forms reduce data entry errors and training time
- Business rules on forms enforce validation without writing code
- Form performance directly impacts user productivity (slow-loading forms kill adoption)
Every Dataverse table gets a default "Main" form automatically when created. This form displays all columns in the order they were created—functional but rarely optimal. Professional implementations require custom form design tailored to how users actually work.
Understanding Form Types
Dataverse provides multiple form types, each optimized for specific scenarios. Understanding when to use each type prevents over-engineering and keeps your app performant.
| Form Type | Purpose | Use Case |
|---|---|---|
| Main | Primary form for creating and editing records | Standard data entry, detailed record view |
| Quick Create | Simplified form for rapid record creation | Adding related records without leaving current screen |
| Quick View | Read-only display of related record fields | Showing customer details on an order form |
| Card | Compact view for interactive dashboards | Dashboard tiles, mobile card views |
| Main - Interactive Experience | Responsive layout that adapts to screen size | Modern responsive forms for desktop and mobile |
Main forms are what users see when they click into a record from a view. You can create multiple Main forms for different security roles—for example, a simplified form for basic users and a detailed form for administrators.
Quick Create forms appear as slide-out panels when users click "New" from a subgrid or lookup. They should contain only essential fields—typically 5-8 fields maximum. Users can create a record and return to their workflow without losing context.
Quick View forms are embedded into other forms to display related record details. For example, an Asset form might include a Quick View form showing the selected Location's address and contact details without requiring navigation.
Basic Form Components
Dataverse forms are built from several key components that you arrange using the form designer. Understanding each component helps you create logical, scannable layouts.
| Component | What It Does | When to Use |
|---|---|---|
| Sections | Group related fields under a heading | Organize fields by category (Contact Details, Address, Preferences) |
| Tabs | Top-level containers that hold sections | Separate major areas of data (General, Related Records, Timeline) |
| Columns (fields) | Individual data entry fields from your table | Every field users need to view or edit |
| Subgrids | Display related child records in a grid | Show all Assets linked to a Location, Comments on a Request |
| Quick View Forms | Show fields from a related parent record | Display Location address details on Asset form |
| Web Resources | Embed HTML, JavaScript, or images | Custom UI elements, interactive maps, charts |
| iFrames | Embed external websites or dashboards | Embedded Power BI reports, external portals |
Tabs vs Sections:
Think of tabs as chapters and sections as headings within chapters. A typical form might have:
- General tab – Basic information section, Classification section, Status section
- Details tab – Technical specifications section, Notes section
- Related tab – Subgrid of related child records
Users navigate between tabs via horizontal navigation at the top of the form. Sections within each tab display vertically down the page.
Creating a New Main Form
Every table comes with a default Main form, but creating a custom form from scratch gives you complete control over layout and field organization.
Step-by-step form creation:
- Navigate to make.powerapps.com and select your environment
- Expand Dataverse → Tables and select your table
- Click Forms in the top navigation
- Click + New form → Main form
- The form designer opens with a default layout containing header, body, and footer
The form designer presents a blank canvas with three main areas:
- Header – Displays at top of form, typically contains key fields like Name, Status, Owner
- Body – Main content area where tabs and sections live
- Footer – Anchored at bottom, usually contains timestamps (Created On, Modified On)
The default form includes one tab called "General" with one section. You'll add more tabs, sections, and fields to build out your complete form structure.
Adding and Organising Fields
Fields (also called columns) are the core of your form. You add them from the Table columns panel on the left side of the form designer.
Adding a field to a section:
- Locate the field in the Table columns panel (left side)
- Drag the field onto a section in your form
- Drop it where you want it to appear
- Repeat for all required fields
Field properties you can configure:
| Property | Purpose | Common Use |
|---|---|---|
| Label | User-facing field name | Change "cr6a3_AssetID" to "Asset ID" |
| Visible | Show or hide the field | Hide technical fields from basic users |
| Locked | Prevent editing (read-only) | Lock auto-calculated fields, system timestamps |
| Required | Force user to enter a value | Make critical fields mandatory at form level |
| Field width | Control how much horizontal space field uses | Make short fields (Status) narrow, long fields (Description) wide |
Field layout best practices:
- Place related fields together (all address fields in one section)
- Put most important fields at the top—users read top-to-bottom, left-to-right
- Use two-column layouts for short fields (Status, Priority, Type)
- Use full-width for long text fields (Description, Notes, Comments)
- Group readonly fields together (Created On, Modified By) in footer or separate section
Organising with Tabs and Sections
Tabs and sections provide the structure that makes forms scannable and logical. Without them, forms become overwhelming walls of fields.
Adding a new tab:
- Click Components in the left panel
- Select 1-column tab or 3-column tab
- Drag it onto the form body (it will appear below existing tabs)
- Click the tab to select it, then set the Label property to name it
Adding a new section within a tab:
- Click Components → 1-column section
- Drag it into the tab where you want it
- Select the section and set its Label (e.g., "Contact Details", "Specifications")
Common tab structures:
| Tab Name | Typical Sections | Content |
|---|---|---|
| General | Basic Information, Classification, Status | Essential fields users need immediately |
| Details | Technical Specs, Additional Info, Notes | Secondary fields not always needed |
| Related | Subgrids of child records | Related Assets, Comments, Attachments |
| Timeline | Activity timeline component | Emails, tasks, notes, appointments |
Section naming best practices:
- Use descriptive names that explain what's inside: "Contact Details" not "Section 1"
- Keep section labels short (2-3 words maximum)
- Group 3-7 related fields per section—too few sections feel disorganized, too many feel cluttered
- Consider hiding section labels for single-section tabs (reduces visual noise)
Configuring Header and Footer
The form header and footer serve specific purposes and should contain different types of fields than the main body.
Header best practices:
The header remains visible as users scroll through the form. Place fields here that provide critical context for the entire record:
- Primary identifier – Name, Title, Asset Number (whatever uniquely identifies this record)
- Status indicators – Status, Stage, Priority (fields users constantly reference)
- Owner – Who's responsible for this record
- Key dates – Due Date, Expiry Date (time-sensitive information)
Limit header fields to 4-6 maximum. Too many header fields make the form feel cramped and reduce space for the body content.
Footer best practices:
The footer is anchored at the bottom of the form. Use it for fields that are important but not frequently accessed:
- System timestamps – Created On, Modified On
- System users – Created By, Modified By
- Record IDs – Technical identifiers needed for integrations
Most forms use the footer for audit fields that satisfy compliance requirements without cluttering the main form. Users can access this information when needed but it doesn't distract from data entry.
Working with Subgrids for Related Records
Subgrids display child records related to the current parent record. They're essential for showing one-to-many relationships directly on the form.
Common subgrid scenarios:
- Display all Assets linked to a Location
- Show Comments posted on a Request
- List Invoices associated with a Contract
- View Tasks assigned to a Project
Adding a subgrid to your form:
- Create a new tab (typically called "Related") or use an existing tab
- Add a new section within that tab
- From Components, select Subgrid
- Drag the subgrid into your section
- Configure the subgrid properties:
| Property | Purpose | Example |
|---|---|---|
| Label | Heading shown above the grid | "Related Assets", "Comments" |
| Table | Which related table to display | Assets (when on Location form) |
| Default view | Which view determines columns shown | "Active Assets", "All Assets" |
| Show Chart | Display chart visualization above grid | Enable for dashboards, disable for forms |
Subgrids automatically filter to show only records related to the current parent. For example, a subgrid of Assets on a Location form only shows Assets where the Location lookup points to the current Location record.
Using Quick View Forms for Related Data
Quick View forms display read-only fields from a related parent record directly on the child form. They eliminate navigation—users see parent record details without leaving the current screen.
When to use Quick View forms:
Imagine an Asset form with a Location lookup. Without a Quick View form, users must click the Location link to see the address. With a Quick View form, the Location's address displays automatically on the Asset form as soon as the Location is selected.
Creating a Quick View form:
- Navigate to the parent table (e.g., Location)
- Go to Forms → + New form → Quick View form
- Add the fields you want to display (e.g., Address, Phone, Manager)
- Save and publish the Quick View form
Adding the Quick View form to the child form:
- Open the child form (e.g., Asset Main form)
- From Components, select Quick view
- Drag it onto the form where you want related data to appear
- Configure the lookup field (Location) and Quick View form to display
- Save and publish
Now when users select a Location on the Asset form, the Quick View form automatically populates with that Location's address and contact details.
Quick View form best practices:
- Include 3-6 fields maximum—Quick Views should provide context, not duplicate the entire parent record
- Focus on fields users need for decision-making (address, status, owner, key dates)
- Position Quick Views near the related lookup field for visual connection
- Remember they're read-only—users cannot edit parent data from a Quick View
Adding Business Rules to Forms
Business rules let you add validation logic, auto-populate fields, show/hide sections, and enforce requirements—all without writing JavaScript.
What business rules can do:
| Action | Example | Use Case |
|---|---|---|
| Set field values | If Priority = High, set Status = Urgent | Auto-populate related fields |
| Show/hide fields | If Type = Equipment, show Serial Number field | Simplify forms by hiding irrelevant fields |
| Make fields required | If Status = Approved, require Approval Date | Conditional validation |
| Lock/unlock fields | If Status = Closed, lock all fields | Prevent editing after certain stages |
| Show error messages | If End Date < Start Date, show error | Validate data entry |
| Show recommendations | If Budget > £50k, recommend manager approval | Guidance without blocking save |
Creating a business rule:
- Open your table → Business rules
- Click + New business rule
- Define the Condition (e.g., "Priority equals High")
- Define the Action (e.g., "Set Status to Urgent")
- Set Scope to "Entity" (runs on forms) or "All Forms"
- Save and Activate the rule
Example business rule:
Requirement: When an Asset's Status changes to "Decommissioned", automatically set the Decommission Date to today and lock the Location field to prevent further changes.
Configuration:
- Condition: Status equals Decommissioned
- Actions:
- Set Decommission Date = Current Date
- Lock Location field
Optimising Form Performance
Slow-loading forms frustrate users and kill adoption. Follow these optimization principles to keep forms responsive.
Performance killers to avoid:
| Problem | Impact | Solution |
|---|---|---|
| 50+ fields on one form | Every field triggers a database query | Split into tabs, hide rarely-used fields |
| Multiple subgrids on General tab | All subgrids load data on form open | Move subgrids to Related tab (lazy load) |
| Complex business rules on every field | Constant re-evaluation slows UI | Limit rules to essential validation only |
| Multiple Quick View forms | Each loads related record data | Limit to 1-2 Quick Views per form |
| Custom JavaScript on every OnChange | Code execution blocks UI thread | Debounce events, use async patterns |
Optimization techniques:
- Tab lazy loading – Place subgrids on tabs other than "General". They won't load until users click the tab.
- Hide unused sections – Sections with no fields still consume space. Delete them entirely.
- Limit lookup fields – Each lookup queries the related table. Combine related lookups into Quick Views instead of multiple individual lookups.
- Use views wisely in subgrids – Complex views with many columns slow subgrid rendering. Create simplified views specifically for subgrids.
- Test on mobile – Forms that load quickly on desktop fiber often crawl on 4G mobile. Test real-world conditions.
- 80 fields on General tab
- 5 subgrids all on first tab
- Multiple Quick View forms
- 15+ business rules
- 25 essential fields on General tab
- Subgrids on Related tab (lazy load)
- 1 Quick View for most important lookup
- 3-5 targeted business rules
Publishing and Testing Your Form
Forms don't take effect until published. Always test in a Sandbox environment before deploying to Production.
Publishing your form:
- Click Save in the form designer to save changes
- Click Publish to make the form available
- Wait for the publish operation to complete (5-10 seconds)
- The form is now live and users will see your changes
Testing checklist:
- Create a new record—do all required fields block save correctly?
- Edit an existing record—do business rules fire as expected?
- Test all lookups—do dropdowns populate with appropriate records?
- Check subgrids—do related records display correctly?
- Verify Quick View forms—do they show parent record data?
- Test on mobile—does the form render properly on small screens?
- Check field-level security—can users only see/edit what they should?
Common issues and fixes:
| Problem | Likely Cause | Solution |
|---|---|---|
| Field doesn't appear on form | Field is hidden or in collapsed section | Check field Visible property, expand sections |
| Business rule doesn't fire | Rule not activated, scope incorrect | Activate rule, set scope to correct form |
| Subgrid is empty | No related records exist, view is too restrictive | Create test records, check view filters |
| Quick View doesn't populate | Lookup field not selected, Quick View not published | Select lookup value, republish Quick View form |
Form Design Best Practices
Professional form design balances usability, performance, and maintainability. Follow these proven patterns:
Layout principles:
- Put critical fields at the top—users read top-to-bottom
- Group related fields into logical sections with descriptive labels
- Use 2-column layouts for short fields, full-width for text areas
- Limit forms to 3-4 tabs maximum (General, Details, Related, Timeline)
- Place subgrids on tabs other than General for lazy loading
Field management:
- Include only fields users actually need—hide technical/system fields
- Make fields required at the table level, not just the form (prevents API bypasses)
- Use clear, business-friendly labels (not technical schema names)
- Lock calculated/auto-populated fields to prevent manual editing
- Test field-level security—ensure users can't see sensitive data
Business logic:
- Use business rules for simple show/hide and validation logic
- Use Power Automate for complex workflows requiring API calls or lookups
- Limit business rules to 5-7 per form (performance)
- Test business rules with all possible field combinations
- Document business rule logic for future maintainers
Performance:
- Target 20-30 fields on the General tab, hide the rest in Details
- Move subgrids to Related tab (they won't load until clicked)
- Limit Quick View forms to 1-2 per form
- Use simple views in subgrids (fewer columns = faster loading)
- Always test forms on mobile devices and slow connections
Accessibility:
- Use descriptive section labels for screen readers
- Ensure tab navigation order is logical
- Provide field help text for complex fields
- Test forms with keyboard-only navigation
- Maintain high contrast for visually impaired users
Next Steps
You've now built a professional Dataverse form with proper structure, business logic, and performance optimization. Expand your form design skills by exploring:
- JavaScript customization – Add client-side logic beyond business rule capabilities
- Web resources – Embed custom HTML/CSS for unique UI requirements
- PCF controls – Build or install custom Power Apps Component Framework controls
- Multiple forms per role – Create specialized forms for different security roles
- Canvas components in forms – Embed Canvas App components for advanced interactions
- Mobile optimization – Design forms specifically for the Power Apps mobile app
The official Microsoft Model-Driven Apps forms documentation provides advanced guidance on form scripting, conditional formatting, and accessibility compliance.