A cluttered model-driven form kills adoption before your app ever gets a chance. Learn how to design professional forms using tabs, sections, subgrids, and Quick View forms — the building blocks that turn raw Dataverse data into a tool people actually want to use.
Imagine you're a sales operations manager who just rolled out a model-driven app for your team. The Account form opens and immediately dumps every field — billing address, shipping address, credit limit, industry code, SIC code, preferred contact method, annual revenue — onto one endless vertical scroll. Reps take one look and go back to their spreadsheets. The data is there, the app is connected, but the form is uninhabitable.
This is the most common failure mode in model-driven app design, and it's almost never about the data. It's about form layout. A well-designed form doesn't just display information — it creates a mental map for the person filling it in. It groups related things together, hides complexity until it's needed, surfaces related records in context, and pulls summary data from connected records without forcing the user to navigate away. By the end of this lesson, you'll be able to do all of that.
What you'll learn:
You should be comfortable with the basics of Dataverse tables and how records relate to each other. If you haven't already, read Dataverse Fundamentals: Tables, Columns, and Rows Explained for Power Apps Makers and Building Your First Model-Driven App: Site Map, Tables, Forms, and Views before continuing. You should also have a basic understanding of how table relationships and lookups work — Designing a Dataverse Data Model: Relationships, Lookups, and Choice Columns covers that ground thoroughly.
Before you drag a single field, you need a mental model of how form layout actually works. Model-driven forms use a strict three-level nesting hierarchy: Tabs contain Sections, and Sections contain Fields. If you try to think of it any other way, the form designer will feel arbitrary and confusing.
Tabs are the top-level containers. They appear as horizontal labels across the top of the form — think "Summary," "Details," "Timeline," "Related." Every field on your form lives inside a tab. You can have as many tabs as you need, and you can show or hide them based on business rules, but at least one tab must always be visible.
Sections live inside tabs. A section is a labeled block within the tab — think of it like a fieldset in an HTML form. Each section has a name (which you can show or hide), and each section has a column layout: either one, two, or three columns. That column layout determines how fields are arranged horizontally within the section. A two-column section places fields side by side in two vertical columns; a three-column section fits three fields across.
Fields live inside sections. A field can span a single column or stretch across the full width of the section, regardless of how many columns the section has. The "field width" setting controls this.
Here's a concrete example to lock this in. Say you're building an Account form. Your first tab might be "Summary." Inside that tab, you have three sections: "Core Information" (two columns, holding Name and Account Number side by side), "Contact Details" (two columns, holding Phone and Email, then Website and Fax), and "Address" (one column, with a full-width address composite field). That's one tab, three sections, and maybe eight fields — all organized logically.
Key insight
The column count on a section is independent of other sections on the same tab. You can have a two-column section stacked on top of a one-column section on the same tab. This lets you create rich, varied layouts within a single tab.
To get started, navigate to make.powerapps.com. In the left navigation, select Tables, then find the table whose form you want to edit — let's use Account as our running example. Select the table, then choose Forms from the top tab bar. You'll see a list of existing forms. Click the form named Account with a form type of Main to open it.
The form editor opens in a split view. The left side is your canvas — the live form layout you're editing. The right side is a properties panel that changes depending on what you have selected. Along the top is a field chooser and a component toolbar.
You'll also see a Form fields panel (sometimes called the field explorer) that lists every column on the table. You drag fields from here onto the canvas.
Tip
Model-driven apps support multiple form types: Main (full-size editing form), Quick Create (a side panel form for fast data entry), Quick View (read-only, embeddable in other forms), and Card (a compact view used in some legacy interfaces). This lesson focuses on Main forms and Quick View forms, which are the most important.
Let's build a realistic Account form layout from scratch. We'll design it for a B2B sales context, so the tabs should match the mental workflow of a sales rep reviewing an account.
The tab plan:
To add a tab, click anywhere on the form canvas where no element is selected, then in the right panel find the + Add tab button (its exact label varies by editor version — look for it in the Components area or use the top ribbon's Insert tab). You can also right-click on an existing tab header to see options.
Once a tab exists, click its label to select it and edit its properties in the right panel:
Rename your first tab to "Summary" by clicking its header and changing the Label field in the properties panel. Repeat for the remaining tabs.
Warning
Don't create tabs just for organizational satisfaction. Every extra tab is a navigation click. If a tab would only contain two or three fields, merge it into a neighboring tab or promote those fields to a section on the Summary tab. Aim for tabs that represent genuinely distinct contexts.
With your tabs in place, you're ready to build sections. Select your Summary tab and look at the canvas — you'll see a default section already there. Click it to select it and rename it in the properties panel.
Let's build the Summary tab layout for our Account form:
Section 1: "Account Identity" — Two columns
Section 2: "Classification" — Two columns
Section 3: "Description" — One column
To add a new section, click inside a tab, then in the right panel or ribbon select + Section. Choose whether it should be one, two, or three columns. Give it a name and decide whether to show the section header label — for most business forms, showing the label helps users orient themselves.
To add a field to a section, find it in the field panel on the left and drag it into the section. Fields snap into the column slots. If a section has two columns, the first field you drop goes into the left slot of the first row, the next goes into the right slot, and so on.
To make a field span the full width (useful for description or address fields), select the field on the canvas and in the properties panel find the Field width setting. Change it from "Auto" or "1 column" to the full column count of the section.
Tip
Section headers can be styled to show or hide. For very dense forms, hiding section labels on inner sections (while keeping them on outer sections) reduces visual noise without losing organization. Try it on your "Account Identity" section if it feels redundant.
Three-column sections are powerful but easy to misuse. A three-column layout is best for dense data that users need to scan quickly rather than read carefully — think financial metrics, flag fields, or a cluster of status indicators. It's a poor choice for data entry because the fields are narrow and the labels get truncated.
Use this rule of thumb:
You can reorder sections by dragging them up or down within a tab. Sections stack vertically, so the user scrolls through them top to bottom on each tab. Put the most critical section at the top of the most important tab.
A subgrid is a list of related child records embedded directly on a parent form. Instead of navigating away from the Account record to find its associated Contacts, you see a live grid of Contacts right there on the form. This is one of the most powerful UX features in model-driven apps — it keeps context intact and eliminates unnecessary navigation.
Subgrids work because of the table relationships you've already defined. If Account has a one-to-many relationship with Contact (one account has many contacts), you can display a Contact subgrid on the Account form. The subgrid automatically filters to show only the contacts related to the current account.
To add a subgrid:
Select a tab where you want the subgrid to appear — in our example, the "Related Records" tab.
Add a new section in that tab. Use one column so the subgrid has full horizontal space.
In the component panel (look for a "Components" or "Insert" option in the ribbon), find Subgrid and drag it into the section.
The subgrid properties panel opens on the right. Set:
Optionally, configure the number of records to display by default (5 or 10 is usually right), and whether the user can edit inline.
Repeat this for the Opportunities subgrid on the same tab. Add another one-column section below and drop in an Opportunities subgrid with similar settings.
Key insight
The "Default view" you assign to a subgrid isn't permanent from the user's perspective — users can switch views from the subgrid header at runtime. But the default view controls which columns are visible when the form first loads. Choose a view designed for "at a glance" context, not a comprehensive data dump.
You can also configure the subgrid to allow Quick Create from the subgrid header. If your Contacts table has a Quick Create form configured, users can add a new related contact without leaving the Account record. This dramatically speeds up data entry workflows.
Warning
Don't add more than two or three subgrids to a single form. Each subgrid fires its own query to Dataverse when the form loads. Multiple subgrids on a single tab will noticeably slow form load time, especially for records with many related rows. If you need many subgrids, spread them across tabs — a tab doesn't load its subgrids until the user clicks it.
A Quick View form is a read-only form component that you embed inside another form to display fields from a related record — specifically, a record on the other end of a lookup field.
Here's the classic scenario: your Account form has a lookup to a Primary Contact. That lookup shows you the contact's name, but nothing else. Wouldn't it be useful to see the contact's phone number, email, and job title right there on the Account form, without clicking into the Contact record? That's exactly what a Quick View form does.
The setup has two parts: first you create the Quick View form on the related table, then you embed it on the parent form.
Navigate to the Contact table in your solution. Select Forms, then click + New form and choose Quick View Form as the form type.
The Quick View form editor opens. It looks like a simplified Main form editor. Add the fields you want to surface — for a Contact, that might be:
Keep Quick View forms tight — four to six fields is ideal. These appear inline on another form, so they need to be compact. Give the form a clear internal name like "Contact Quick View - Account Form" so you can find it later.
Save and publish the Quick View form.
Go back to your Account Main form. Create a new section on your Summary tab — call it "Primary Contact Info" and use two columns.
In the component panel, find Quick View (sometimes listed as "Quick View Form" or "Reference Panel Quick View"). Drag it into the section. In the properties panel:
Save the Account form and publish.
Now when a user opens an Account record that has a Primary Contact set, they'll see that contact's key details — phone, email, job title — right on the Account form without a single click.
Tip
Quick View forms are read-only by design. Users who want to edit the related record need to navigate to it. That's intentional — Quick View forms are for context, not editing. If users frequently need to edit the related record from here, consider adding a direct link button using a URL field or a command bar button instead.
Let's put this all together in a realistic scenario. You're building a form for a Project table in a project management app. The Project table has:
Your mission:
Open the Main form for the Project table in the form editor.
Rename the default tab to "Overview." Inside it, create two sections:
Add a second tab called "Team & Tasks." Inside it, create:
Create a Quick View form for the Client (Account/Company) table that shows: Company Name, Main Phone, Website, and Account Owner.
Return to the Project Main form. In the "Client" section on the Overview tab, add a Quick View component using the Client lookup field and the form you just created.
Save and publish. Open a test Project record to verify:
"My subgrid shows all records, not just related ones." You forgot to enable "Show related records only" in the subgrid properties. Go back into the form editor, select the subgrid, and confirm that setting is on. Also verify the relationship is correctly configured — the subgrid can only filter by relationship if the relationship actually exists in Dataverse.
"My Quick View form shows blank / no data." This almost always means the lookup field on the parent record is empty — the current record isn't linked to a related record yet. Quick View forms are blank when the lookup is null. Also check that you published the Quick View form after creating it. Saving isn't enough — it must be published.
"I can't find the Quick View component in the form editor." Make sure you're editing a Main form, not a Quick Create or Card form. Quick View components can only be embedded in Main forms. Also make sure you're looking in the right panel — in newer form editor versions, Quick View is under "Components," not under the field list.
"Tabs are rendering but fields are in a different order than I designed." The form editor renders fields in the order they appear in the sections, filling left-to-right, top-to-bottom within each column. If your layout looks different at runtime, check for hidden fields that are still taking up layout space. A field set to "Visible by default = off" still occupies its slot in the form XML — it's just invisible. Use a business rule to hide it cleanly, or remove it from the form entirely and show it conditionally.
"The form is loading slowly." You likely have too many subgrids on a single tab, or your subgrids are using views with too many columns or no filters. Move subgrids to secondary tabs, or replace heavy subgrids with a reference panel (available in some environments as an alternative to the classic subgrid). Also check if any Quick View forms are using lookups that trigger additional queries on load.
Warning
Model-driven form changes affect all users of that form immediately after publishing. There's no staging or preview mode for end users. If you're making significant layout changes to a production form, do the work in a dev/test environment and use solution layering to move changes — don't edit production directly.
You now have a complete toolkit for designing professional model-driven forms. You understand the tab-section-field hierarchy and why it matters. You can design multi-tab layouts that match real user workflows rather than dumping all data on one scroll. You know when to use one, two, or three column sections based on data type and user behavior. You can add subgrids to surface related child records in context, and Quick View forms to pull in read-only data from lookup relationships without forcing navigation away.
The pattern you've learned here — grouping by mental workflow, separating editing from scanning, surfacing related context inline — is the same pattern used in enterprise CRM platforms that cost hundreds of thousands of dollars. Model-driven apps let you build that experience with configuration rather than code.
A few directions to explore next:
The form is the front door to your data model. Design it well, and your users will actually walk through it.