Learn how to build Quick Forms and Card Forms in Power Apps model-driven apps so users see rich, contextual summaries of related records directly inside lookup flyouts and subgrids — no navigation required. This hands-on lesson covers creating, configuring, and troubleshooting both form types from scratch.
Picture this: your sales team is working inside a model-driven app, looking at an open Opportunity record. They spot a lookup field pointing to the Account that owns the deal. They hover over it — and nothing useful happens. They click it, land on the full Account form, scroll around to find the phone number and primary contact, then navigate back. Multiply that by fifty reps doing it forty times a day, and you've got a productivity problem that has nothing to do with your data model and everything to do with form design.
Quick Forms and Card Forms exist to solve exactly this. They are compact, read-only summaries of a related record that surface in context — right inside a lookup flyout, or embedded in a subgrid row — without requiring the user to leave the record they're working on. Once you configure them properly, that Account lookup shows name, phone, account owner, and tier without a single extra click. The subgrid on your Case form shows each related Task with its due date and status neatly formatted in a card layout.
By the end of this lesson, you will be able to build Quick Forms and Card Forms from scratch, wire them to lookup columns and subgrids, and make deliberate decisions about which fields to surface based on how your users actually work.
What you'll learn:
This lesson assumes you're comfortable with the basics of model-driven app structure. You should know what tables, columns, and relationships are in Dataverse — if those concepts feel shaky, read Dataverse Fundamentals: Tables, Columns, and Rows Explained for Power Apps Makers first. You should also have built at least one model-driven form before. If you haven't, Designing Model-Driven Forms: Sections, Tabs, Subgrids, and Quick View Forms gives you the foundational vocabulary this lesson builds on. A working Dataverse environment with the System Customizer role is required.
Model-driven apps have several form types, and they serve different purposes. Main forms are what users open to read and edit a record in full. But two other types exist specifically for the "summary at a glance" use case: Quick Forms (sometimes called Quick View Forms) and Card Forms.
A Quick Form is a read-only snapshot of a related record, displayed inline on another record's main form via a Quick View Form control. The control is bound to a lookup column on the current table. When a user opens a record that has a lookup pointing to, say, a Contact, the Quick View Form control can show that Contact's job title, email, and phone without opening the Contact record.
Think of it like a hover card on LinkedIn — you see the essential summary without leaving the page you're on.
Quick Forms are created and managed on the related table. If you want a summary of an Account to appear on an Opportunity form, you create the Quick Form on the Account table.
A Card Form controls how individual records are displayed inside a subgrid when that subgrid is in "card" layout mode. A subgrid on a Case form might list related Tasks — the Card Form on the Task table determines which fields appear in each row of that subgrid.
Card Forms are especially useful when your subgrid contains records that users need to scan quickly. Rather than a dense table of columns, each record can display as a small card with a title, a couple of supporting data points, and a status indicator.
These two form types work alongside views, but they aren't views. A Lookup View controls which records are shown in the search dropdown when a user clicks a lookup field. A Quick Form controls what information is displayed about the already-selected record. Understanding this distinction prevents a very common configuration mistake. You can learn more about how lookup views work in Configuring Model-Driven App Views as Default Views, Quick Find Views, and Lookup Views.
Note
Quick Forms and Card Forms are both read-only by design. Users cannot edit fields through them. If your goal is inline editing, you want an editable subgrid, which is a different configuration path.
Let's work through a concrete scenario. You have an Opportunity table with a lookup to Account. You want anyone viewing an Opportunity to see the Account's phone number, industry, account tier (a choice column), and owner name without navigating away.
Navigate to make.powerapps.com and make sure you're in the right environment. In the left navigation, click Tables, then search for and open the Account table. From the Account table page, click the Forms tab.
You'll see a list of forms already associated with the Account table — likely a main form called "Account," a Quick View Form, and possibly others. You can edit an existing Quick Form or create a new one.
To create a new one, click New form and select Quick view form from the dropdown. The form designer opens with a minimal single-column layout.
Quick Forms support tabs and sections like main forms, but keep them lean. A Quick Form that crams in twenty fields defeats its purpose. Aim for five to eight fields that answer the most common "I need to know this right now" questions.
For our Account summary, we'll add:
In the form designer, the left panel shows available columns from the Account table. Drag each column into the form canvas. Arrange them in a logical reading order — primary name at top, contact info next, then categorization fields.
Tip
Quick Forms render in a fixed-width flyout panel, so column layout matters. A two-column section works well for short fields like phone and industry side by side, but owner names can be long — give those their own full-width row to avoid truncation.
Click Save, then give the form a descriptive name like Account Quick View – Opportunity Context. Naming it with context helps if you later create multiple Quick Forms for different use cases. Click Publish.
Creating the Quick Form on Account is only half the job. Now you need to place a Quick View Form control on the Opportunity main form and tell it which lookup to read from and which Quick Form to display.
Navigate back to Tables, open Opportunity, and click the Forms tab. Open your main Opportunity form in the form designer.
Choose a logical location for the Account summary — a section near the top of the form, ideally close to or below the Account lookup field itself. Users should see the lookup field (where they set the relationship) and the Quick View summary close together.
If you don't have a dedicated section for this yet, add one. Click on the section you want to modify, then use the Add section button to insert a new one. Label it something like "Account Summary" so it's obvious in the designer.
In the left component panel, look for Quick view form under the form components list (sometimes it appears under "Related data" or you can find it by searching "quick view" in the component search bar). Drag it into your Account Summary section.
A configuration panel appears on the right. You'll see two critical settings:
accountid or similar).Once you configure both settings, the control renders a preview in the designer showing the fields you selected on the Account Quick Form.
Click Save and Publish the Opportunity main form.
Open your model-driven app, navigate to an Opportunity record that has an Account assigned. You should see the Account Summary section populate with the Account's phone, industry, tier, and owner — pulled live from the related Account record.
Warning
If the Account Summary section appears blank after publishing, check two things first: (1) the Opportunity record actually has an Account selected in the lookup, and (2) the user running the app has at least Read permission on the Account table. Quick View Forms fail silently when security blocks access to the related record — they simply show nothing rather than an error.
Now try changing the Account lookup to a different Account. The Quick View Form updates immediately without a page reload. This live-binding behavior is one of the reasons Quick Forms are so effective — the summary always reflects the currently selected related record.
Now let's tackle Card Forms. The setup is similar but the target is a subgrid rather than a lookup control.
By default, a subgrid in a model-driven form shows records in a tabular list view — rows and columns like a spreadsheet. But you can switch a subgrid to card layout mode, which renders each related record as a small tile. The Card Form on the related table controls what each tile displays.
For our next scenario: a Case (service request) table has a subgrid showing related Tasks — follow-up actions the support team needs to complete. You want each Task card to show the task name, due date, assigned-to user, and status, laid out cleanly.
Navigate to Tables, open Task, and go to the Forms tab. Click New form and select Card form.
The Card Form designer looks different from other form types. It has a specific structure with three zones:
Map your fields:
Keep the Card Form even more minimal than the Quick Form. Card forms appear at small scale inside a subgrid, so fields beyond four or five become visual noise.
Key insight
The Card Form header is what renders in the card title. If you leave it blank or assign a field that's often empty, your cards will look anonymous in the subgrid. Always anchor the header to the field users think of as "the name" of that record.
Name the form Task Card – Case Subgrid and publish it.
Now open your Case main form in the form designer. Locate the existing Tasks subgrid, or add one. If you need to add a subgrid, use the component panel, drag in a Subgrid component, and configure it to show the Task table, filtered to tasks related to the current Case.
Click on the Tasks subgrid to select it. In the right-side properties panel, look for the Controls tab (or "Control" section depending on your designer version). Here you can add or configure the control type.
Find the Card form property and select your Task Card – Case Subgrid form from the dropdown. You'll also want to ensure the subgrid is set to display in card view mode — look for a View selector or layout toggle. In modern model-driven apps using the Unified Interface, the card layout activates when a Card Form is assigned; the subgrid automatically renders cards instead of rows when this is configured and the grid is in "read-only" mode.
Save and publish the Case form.
Tip
Card forms work best when the subgrid is set to read-only mode. If you've enabled an editable grid control on the same subgrid, the Card Form assignment may be ignored in favor of the editable grid's tabular layout. You typically can't have both active simultaneously — choose based on whether your users need to edit directly in the subgrid or just scan and click through.
One underused feature is that a table can have multiple Quick Forms, and different main forms can use different ones. This matters when the same related table is looked up from different contexts.
For example, your Contact table might be looked up from both Opportunity (where sales reps care about title, phone, and preferred contact method) and Case (where support agents care about account membership, language preference, and support tier). Create two Quick Forms on Contact:
Wire each to the Contact lookup Quick View Form control on the respective form. The underlying data model is the same; you're just curating the summary for the audience.
This also ties into the broader principle that designing a Dataverse data model is only part of the work — how that data surfaces in UI is equally important for adoption.
Work through this end-to-end configuration using a trial environment or your development environment.
Scenario: You have a Project table with a lookup to a Client (Account) table, and a subgrid showing related Milestones (a custom table with Subject, Target Date, Completion %, and Status columns).
Part 1 — Quick Form:
Part 2 — Card Form:
Stretch challenge: Create a second Quick Form on Account called "Client Quick View – Finance Context" that shows Account Name, Annual Revenue, Credit Limit (if you have it), and Billing Address City. Then create a Finance main form on your Project table (or a different form variant) and wire this second Quick Form to it. Confirm that the two main form variants each show their own tailored Account summary.
The Quick View Form section shows nothing, no error. This is almost always a permissions issue. The signed-in user doesn't have Read access to the related table. Check the security role assigned to the user and confirm it includes at least User-level Read on the related table. Model-Driven App Security covers how to verify and adjust those settings.
The Quick View Form shows stale data. Quick View Forms are live-bound — they should update when the lookup changes. If you're seeing old data persist, try clearing the browser cache or confirming you're on a published (not draft) version of the form.
The Card Form isn't rendering — the subgrid still shows a plain list. Verify two things: (a) you published the Card Form on the related table, and (b) you saved and published the main form after assigning the Card Form in the subgrid control properties. Both publications are required. Also check whether an editable grid control is competing with the card layout.
You can't find the Quick View Form component in the form designer. In the modern Power Apps form designer, Quick View Form is under the "Display" category of components. If you don't see it, make sure you're not editing a Quick Form itself (you can't nest quick forms) and that your table has at least one lookup column configured.
Your Quick Form is publishing but the dropdown in the lookup control doesn't show it. Confirm the Quick Form's status is Active and that it's associated with the same table as the lookup target. If you created the Quick Form on Contact but your lookup points to Account, it won't appear.
Warning
Avoid putting too many Quick View Form controls on a single main form. Each control makes a separate read call to Dataverse when the form loads. Four or five controls each pulling a related record is generally fine; ten or more will noticeably slow form load times, especially on mobile. Be intentional about what summaries your users actually need.
Quick Forms and Card Forms are small configurations with outsized impact on user experience. They answer the question your users are always implicitly asking: "Who or what is this record connected to, and what do I need to know about that right now?" By surfacing that information in context — in a lookup flyout or a subgrid card — you reduce navigation, reduce errors, and make the app feel genuinely intelligent rather than just functional.
Here's what you accomplished in this lesson:
From here, consider exploring how Formula Columns and Rollup Columns in Dataverse can give you pre-computed summary values to surface on Quick Forms — showing things like "Total Open Cases" on an Account Quick View without loading the related records. You should also look at Configuring Model-Driven App Dashboards for the next level of aggregate visibility across your entire dataset.
If your app is growing in complexity and you're managing multiple form variants and controls across many tables, the time to start organizing your work into properly managed solutions is now — Solutions for Model-Driven Apps: Publishers, Managed vs Unmanaged, and Solution Layering will show you how.