Learn how to configure Quick Create Forms and Quick View Forms in model-driven apps to reduce friction for record creation and surface related data in context. This hands-on lesson walks through setup, field selection strategy, and common troubleshooting for both form types.
Picture this: your sales team is on a call, a prospect mentions a colleague who should also be in the system, and the rep needs to create a new contact record right now — without losing their place in the current account record, without navigating to a different page, and without filling out forty fields that can wait until later. Or consider your support staff, who are working a case and need to glance at the related customer's address and contract tier without opening a separate tab. These are friction points that slow down real work, and they're exactly the problems that Quick Create Forms and Quick View Forms solve.
Quick Create Forms give users a compact, focused dialog for creating new records without leaving their current context. Quick View Forms let users see read-only data from a related record directly embedded on the form they're already working in. Together, they make your model-driven app feel polished and thoughtful instead of clunky and bureaucratic. By the end of this lesson, you'll know how to configure both form types, understand when to use each one, and avoid the common mistakes that trip up new makers.
What you'll learn:
You should be comfortable with the basics of Dataverse tables, columns, and relationships before diving in. If you're new to Dataverse, read Dataverse Fundamentals: Tables, Columns, and Rows Explained for Power Apps Makers first. You should also have built at least one model-driven app and understand how forms and views work — if not, Building Your First Model-Driven App: Site Map, Tables, Forms, and Views will get you there. Some familiarity with table relationships (especially lookups) is essential for the Quick View Form section, covered in Designing a Dataverse Data Model: Relationships, Lookups, and Choice Columns.
Before touching any configuration, it's worth building a clear mental model of what these two form types actually do. They solve completely different problems, even though they're both "smaller" than a standard main form.
A Quick Create Form is a lightweight dialog that slides in from the right side of the screen (or pops up as a modal) when a user needs to create a new record. The critical thing to understand is that this dialog appears on top of whatever the user is currently doing. They never navigate away. When they save and close the Quick Create Form, they're right back where they started.
Here's a concrete example: imagine a recruiting app where a recruiter is viewing a Job Posting record and wants to quickly log a new Candidate. Instead of opening the full Candidate form (which might have tabs for employment history, references, skill assessments, and interview notes), the Quick Create Form shows only the five or six fields needed to get the candidate into the system: name, email, phone, source, and the job posting lookup. The rest gets filled in later.
Quick Create Forms can be triggered from:
A Quick View Form is fundamentally different. It doesn't let users create anything — it's read-only. Instead, it displays fields from a related record directly embedded inside another form. The embedded block updates automatically based on whatever is currently selected in a lookup field on the host form.
The classic use case: your Case form has a lookup to Account. With a Quick View Form, you can embed account details — industry, annual revenue, support tier, primary contact name — directly on the Case form, so the support agent doesn't have to open the account record in another tab just to see that context. The moment the agent changes the Account lookup to a different company, the Quick View block updates to show that company's details instead.
Key insight
Quick View Forms read data from a related record through a lookup relationship. If your form doesn't have a lookup column, you have nothing to "view" from. The relationship comes first; the Quick View Form surfaces it.
The very first thing you need to do is tell Dataverse that a particular table is allowed to be created via a Quick Create dialog. This is a table-level setting, not a form-level one.
Navigate to make.powerapps.com and open your solution. Find the table you want to configure (let's say Candidate) and open its settings. You can do this by clicking the table name, then selecting the Properties or Settings option (the exact label depends on whether you're in the classic or modern editor — look for a gear icon or "Edit table" option).
In the table properties panel, look for a section called Options or Advanced options. There you'll find a checkbox labeled Allow quick create. Check that box and save the table.
Warning
If you skip this step, the Quick Create Form you build will have no way to appear. The + button on subgrids and the global command bar both check this table setting before they decide whether to show the Quick Create dialog or open the full main form. It's the most commonly missed step.
Now navigate to the Forms section of your table. You'll see a list of form types — Main, Quick Create, Quick View, and possibly Card. If no Quick Create form exists yet, click Add form → Quick Create Form. If one already exists (Dataverse often creates a default one for standard tables), open it to edit it.
The Quick Create Form editor looks nearly identical to the Main Form editor. You get a canvas with sections, and you drag columns from the right-hand panel into those sections. The difference is structural: Quick Create Forms are intentionally flat. They support only a single column layout with no tabs. This constraint is by design — a dialog that opens over another screen doesn't have room for a tabbed interface.
This is where many makers make their first big mistake: they add too many fields. The whole point of a Quick Create Form is to capture the minimum viable data to create a useful record. Think about it from the user's perspective — they're in the middle of doing something else. Every additional field is friction.
A good rule of thumb: five to eight fields maximum. Focus on:
Tip
You don't need to include every required field if you can set a default value through Power Automate or a business rule that fires on create. But if a required field has no default and it's not on the Quick Create Form, the save will fail with a confusing error. Test this before going live.
For our Candidate example, the Quick Create Form might include:
After configuring the form, click Save and then Publish. The publish step is easy to forget, but nothing you've done will be visible in the app until you publish. In a solution context, you can also publish all customizations from the solution page.
Once published, test the Quick Create Form by opening the app, navigating to a view of a table that references Candidates via a subgrid (like the Job Posting main form), and clicking + New Record on the subgrid. You should see your compact dialog appear.
Quick View Forms involve a two-step process: first, you build the Quick View Form on the related table (the one being looked up), and then you add it to the host form (the one where users will see it embedded).
Let's use a concrete scenario: you're working on a Case table that has a lookup to Account. You want to show account details on the Case form.
Go to the Account table's Forms list and click Add form → Quick View Form. Give it a meaningful name, like "Account Quick View — Case Form." The name matters because a table can have multiple Quick View Forms, and you want to know which is which when you're on the Case form editor choosing one.
Add the fields you want case agents to see. These are read-only — users won't be able to edit them here. Good candidates for an Account Quick View Form might be:
Note
You can include fields from the related table only — not from its related tables. For example, if Account has a lookup to Territory, you can't drag Territory Name directly onto the Account Quick View Form. You'd need a formula column or calculated column on Account to bring that data forward first.
Quick View Forms support sections and multiple columns within a section, which gives you a bit more layout flexibility than Quick Create Forms. Take advantage of this — a two-column layout lets you show more context without making the embedded block tall and dominating.
Save and publish the form.
Now open the Case main form in the form editor. This is where you'll embed the Account Quick View Form.
In the form editor, you need to add a component called a Quick View Form control. In the modern form designer (make.powerapps.com):
The Quick View block will now appear on the Case form canvas as a labelled section with placeholder field names. It won't show live data in the designer — that only happens in the running app.
Tip
Place the Quick View block near the top of the form or in a sidebar section. Users need the related account context before they start filling out the case details, not after scrolling past everything else.
Open the app and navigate to a Case record that has an Account populated in the lookup. You should see the Quick View block showing that account's details. Now change the Account lookup to a different account and watch the Quick View block update. If it doesn't update immediately, save the record — some environments require a save before the Quick View refreshes.
Warning
If the Account lookup field on the Case form is empty (the case isn't linked to an account), the Quick View block will be blank. This is expected behavior. Consider using a business rule to make the Account lookup required if the Quick View data is critical to the workflow.
A single main form can have multiple Quick View blocks. For example, a Case form might have one Quick View showing Account details (via the Account lookup) and another showing Contract details (via a Contract lookup). Each Quick View block is configured independently, pointing to a different lookup and a different Quick View Form.
The practical limit is usability, not a technical constraint. More than two or three Quick View blocks on one form starts to feel cluttered and slows perceived form load time. Be intentional.
When a Quick Create Form is opened from a subgrid on a parent record, Dataverse is smart enough to pre-populate the lookup field on the child record pointing back to the parent. For example, if you open the Candidate Quick Create Form from a subgrid on a Job Posting record, the Job Posting lookup on the Candidate form will already be filled in with the current job posting. This is one of the most powerful UX features of Quick Create — it removes a step that would otherwise require the user to manually set the relationship.
For this to work, the lookup column connecting the two tables must be present on the Quick Create Form. If you leave it off (thinking "the system will handle it"), the pre-population will fail silently and the new record won't be linked to the parent. Always include the relevant lookup on your Quick Create Form.
If you're interested in more advanced form layout strategies — including how subgrids interact with related records and when to use a Quick View Form vs. a subgrid — Designing Model-Driven Forms: Sections, Tabs, Subgrids, and Quick View Forms covers the full spectrum of form design decisions in depth.
Work through this exercise using a trial or developer environment. We'll configure a Quick Create Form and a Quick View Form for a simple recruiting scenario.
Setup: Make sure your environment has a Job Posting table and a Candidate table. The Candidate table should have a lookup to Job Posting. If you're building these tables fresh, also add columns: Candidate Full Name (text, required), Email (email), Phone (phone), Source (choice: LinkedIn / Referral / Job Board / Direct Application), and Status (choice: New / Screening / Interview / Offer / Closed). The Job Posting table should have: Title (text, required), Department (text), and Hiring Manager (text).
Part 1 — Quick Create Form:
Part 2 — Quick View Form:
"The + New button opens the full main form instead of the Quick Create dialog." You almost certainly forgot to enable "Allow quick create" on the table. Go back to the table settings, check that box, and save. No re-publish of the form is needed — this is a table-level setting that takes effect immediately.
"Required fields cause an error but they're not on my Quick Create Form." Dataverse enforces table-level required columns regardless of whether they appear on the form. Either add the field to the Quick Create Form, set a default value using a business rule or Power Automate flow, or change the field's requirement level if it's truly optional.
"The Quick View block shows no data even when the lookup is populated." First, confirm the Quick View Form is published. Second, check that the lookup field you specified when adding the Quick View control actually matches the relationship — it's easy to accidentally select a similarly-named lookup that points to a different table. Third, try saving the record and refreshing.
"I can't find the Quick View option in the component list." In the modern form designer, Quick View might be listed under Related data or Display components rather than at the top level. Use the search box in the components panel and type "quick" to filter the list.
"The Quick Create Form appeared once but now isn't showing." Check whether someone published a newer version of the main form or the table settings. Also confirm the user's security role includes Create privileges on the table — if they lack create access, the system won't show the Quick Create dialog at all. Security role configuration for table access is covered in Configuring Dataverse Table Permissions in Model-Driven Apps.
"My Quick View Form is showing but one field is blank even though data exists on the related record." Check whether the field is secured with column-level security. If the user's security role doesn't grant read access to that specific column, it will appear blank in the Quick View block even if the data is there. This is a feature of column-level security in Dataverse, not a bug.
You've covered a lot of ground. Quick Create Forms reduce friction for record creation by giving users a focused dialog without breaking their workflow. Quick View Forms surface related record data directly in context so users don't have to jump between screens. Both form types require deliberate field selection — more fields is almost never better.
The key things to remember:
Where to go next: If you want to deepen your form design skills, Designing Model-Driven Forms: Sections, Tabs, Subgrids, and Quick View Forms walks through the full range of layout decisions for main forms. If you're thinking about how views work alongside your forms — particularly the lookup views that appear when users search from a Quick Create lookup field — Creating and Customizing Views in Model-Driven Apps is the right next stop. And if you want to add validation logic to the data your Quick Create Form collects, Business Rules in Dataverse: Validation and Field Logic Without Code will show you how to do that without writing a single line of code.