Quick Create forms let users create related records inline without losing their place — but only if they're properly configured. This lesson teaches you how to build, enable, and fine-tune Quick Create forms across tables and lookup fields, and what happens when the fallback to Main form kicks in.
Picture this: your sales team is logging a new opportunity, and while filling it out they realize the Contact they need doesn't exist yet. In a poorly configured app, they'd have to abandon the opportunity form, navigate to Contacts, create the record there, come back, and try to remember where they were. In a well-configured app, a small modal dialog pops up, they fill in a handful of essential fields, hit save, and the new contact is immediately selected — all without leaving the opportunity. That's the power of a Quick Create form.
Quick Create forms are one of those features that sounds simple but has real depth once you start configuring them across multiple tables and scenarios. When they work well, users barely notice them — record creation feels effortless. When they're missing or misconfigured, users either get a jarring full-page redirect or, worse, they can't create related records inline at all. In this lesson, you'll learn exactly how Quick Create forms work, how to build and configure them, and how the fallback to the Main form works when a Quick Create form isn't available.
By the end of this lesson, you'll be able to design a fast, user-friendly record creation experience across your entire model-driven app — whether users are creating records from the nav bar, from a subgrid, or from a lookup field.
What you'll learn:
Before diving in, you should be comfortable with:
A Quick Create form is a compact, modal form that slides in from the right side of the screen. It lets a user create a new record without navigating away from the page they're currently on. The modal presents a small subset of fields — typically just the ones needed to create a valid, useful record — and when the user saves, the new record is created in Dataverse and, if the user was filling in a lookup field, that new record is automatically selected.
Contrast this with the Main form, which is the full-featured editing form for a record. The Main form opens on its own page and typically contains all columns, subgrids, tabs for related records, business process flows, and timelines. Main forms are designed for deep data entry and editing; Quick Create forms are designed for speed.
Think of it like the difference between a hotel's express check-in kiosk and the full front desk experience. The kiosk handles 80% of arrivals in 20% of the time. The front desk is still there for complex situations.
Here are the three places Quick Create forms appear in a model-driven app:
Key insight
Quick Create forms are entirely optional. If no Quick Create form exists for a table, or if the feature isn't enabled, the app falls back to opening a full Main form page. This fallback behavior is intentional and controllable — understanding it lets you decide when to use Quick Create and when the full form is the right experience.
Before you can use a Quick Create form, the table itself must have Quick Create enabled. This is a table-level setting, separate from the form configuration.
To enable it, navigate to make.powerapps.com and open your solution. Find the table you want to configure — let's say you're working with a Contact table. Click into the table's settings by selecting it, then choosing "Settings" from the top menu or the ellipsis menu.
In the table settings panel, look for the section labeled "Create and update" or "Advanced options" depending on your interface version. There you'll find a checkbox called "Allow Quick Create" (sometimes labeled "Enable quick create"). Check that box and save.
Warning
This setting is not enabled by default on all tables. Standard Dataverse tables like Contact and Account usually have it enabled already, but custom tables you create will not have it checked unless you explicitly turn it on. If your Quick Create form isn't appearing for a custom table, this is the first thing to check.
Once enabled at the table level, the table is eligible to use Quick Create forms. But you still need to create the form itself and make sure it's active.
With Quick Create enabled on the table, navigate to the Forms section of that table. You'll see a list of forms organized by type: Main, Quick View, Quick Create, and Card. If no Quick Create form exists yet, you can create one from scratch. If one already exists (Microsoft ships default Quick Create forms for standard tables), you can customize it.
To create a new Quick Create form, click Add form and select Quick create form from the dropdown.
The Quick Create form designer looks very similar to the Main form designer, but there are important structural constraints:
This last point is worth emphasizing: the Quick Create form is intentionally lean. Its job is to capture just enough information to create a valid record. If a user needs to fill in a full record with related data, that's what the Main form is for.
Let's walk through a realistic example. Imagine you're building an app for a consulting firm. The Project table has columns like:
For the Main form, all of these belong. For the Quick Create form, you'd strip it down to:
That's it. Five fields that give you a valid, meaningful record. A user encountering this while filling in a related record doesn't need to set the billing type right now — they can open the full record after creation to complete it.
To add fields to your Quick Create form, drag them from the Columns panel on the left into the form canvas. Arrange them in logical order — required fields first, then the most important contextual lookups.
Tip
Required fields defined at the column level (in Dataverse) will be enforced on the Quick Create form just like on the Main form. If a user can't complete required fields quickly, they'll be frustrated. Consider whether a column should be "Business Required" at the Dataverse level vs. "Required" only via a business rule on the Main form. Required fields that only make sense after initial creation are better enforced via business rules scoped to the Main form rather than at the column level.
Once you've added your fields, save and publish the form. In the form list, make sure the Quick Create form's status is set to Active. Inactive forms won't be used.
For each form type, Dataverse allows multiple forms to exist — and you can control their order. The form at the top of the list (highest order value) is presented to users first. For Quick Create forms, this means if you have multiple Quick Create forms for the same table, the first active one the user's security role can access is used.
Note
Quick Create forms respect security roles just like Main forms do. If a user's security role doesn't grant access to a specific form, the system moves down the list to the next available form. This means you can create different Quick Create forms for different roles — a simplified one for basic users, a slightly more detailed one for managers — without any code. See Model-Driven App Security: Configuring Security Roles, Field Permissions, and Team-Based Access for Table Data for how security roles interact with forms.
To manage form order, go to the Forms list for the table. Select multiple forms and use the Form Order button in the command bar to set the sequence. Remember: this order matters for fallback behavior within the same form type.
Table-level Quick Create enablement is necessary but not sufficient. You also need to make sure your app is configured to offer Quick Create entry points.
When you build a model-driven app, tables are added through the app designer. For each table added to your app, there's an option to enable the Quick Create button in the global navigation bar. In the classic app designer, you'd see a checkbox for this on each table's settings pane. In the modern app designer (make.powerapps.com → Apps → your app → Edit), navigate to the Navigation panel, select the table's subarea, and confirm Quick Create is available.
Additionally, the "+" button in the nav bar is a global feature — it shows Quick Create-enabled tables as options. If a table doesn't appear in that menu, either Quick Create isn't enabled at the table level, there's no active Quick Create form, or the table isn't included in the app with Quick Create turned on.
For lookups, Quick Create behavior is slightly different. When a user is filling in a lookup field on a form and types a name that doesn't match an existing record, a dropdown appears with a "+ New [Table Name]" option. Clicking this triggers the Quick Create form for the related table — if one exists and is enabled. This is completely automatic once Quick Create is properly set up; you don't need to configure it per-lookup.
Here's where things get interesting. What happens when a user triggers a Quick Create entry point but no Quick Create form is available? This is the fallback behavior, and understanding it is critical for a smooth user experience.
The fallback hierarchy works like this:
This fallback is actually quite thoughtful. It means your app won't silently fail — users can still create records, just not inline. But it can cause a jarring experience if you haven't planned for it.
Consider this scenario: a user is filling in a lookup on an Opportunity form for the related Territory table. Your Territory table has Quick Create enabled, but the active Quick Create form was accidentally deactivated during a solution deployment. Now, when users click "+ New Territory" from the lookup, they get launched to a full Territory Main form in a new browser tab. They create the territory, come back, and have to re-search for it in the lookup. Not ideal.
Warning
When a Main form fallback happens from a lookup context, the newly created record is not automatically populated back into the lookup field. The user must go back and manually search for it. This is a significant UX difference from the Quick Create experience, where the record is selected automatically. Always verify your Quick Create forms are active after solution imports.
The fallback to the Main form is also intentional in some cases. For complex tables where inline creation would be confusing — tables with mandatory related records, complex validation, or multi-step processes — it's perfectly valid to leave Quick Create disabled and let the fallback open the full Main form. This is a design decision, not a failure mode.
Lookup fields have an additional configuration layer. When you're designing a Main form and you add a lookup column to it, the lookup field's properties include an option that controls Quick Create behavior for that specific lookup.
In the form designer, click on a lookup field to select it, then open its Properties panel. You'll see an option labeled something like "Disable quick create" or in newer interfaces, a toggle for quick create behavior. If this is checked/enabled, that particular lookup field will NOT offer the Quick Create option — even if the related table has Quick Create properly configured.
This gives you fine-grained control. For example, on your Opportunity form, you might want Quick Create available on the Contact lookup (because contacts are frequently new) but disabled on the Price List lookup (because price lists should always exist and be selected from a pre-approved list, not created on the fly).
Tip
Disabling Quick Create on a specific lookup doesn't prevent users from navigating away and creating the record manually — it just removes the inline option from that lookup's dropdown. If the goal is to prevent record creation entirely, that's a security role configuration, not a form configuration.
One of the most valuable behaviors of Quick Create forms in lookup and subgrid contexts is automatic pre-population. When a Quick Create form opens in the context of a relationship, Dataverse intelligently pre-fills fields based on that relationship.
For example, if you're viewing a Project record and a subgrid shows related Project Tasks, clicking "Add New" from that subgrid opens the Quick Create form for Project Tasks. The Project lookup field on the task is automatically set to the current Project record — the user doesn't need to fill it in.
Similarly, if you have a one-to-many relationship between Account and Contact, and you open a Contact Quick Create form from within an Account record's subgrid, the Account lookup on the Contact form will be pre-populated with that Account.
This pre-population only works for direct relationship columns. Other fields you might want pre-filled — like a default Status value or a default Owner — should be set via column defaults in Dataverse or via a business rule, not by relying on Quick Create context.
Let's put this together with a practical exercise. You'll create a Quick Create form for a Vendor table in a procurement app.
Setup: Assume you have a Dataverse environment with a custom Vendor table containing these columns: Vendor Name (text, required), Primary Contact (text), Category (choice: Supplier / Contractor / Consultant), Website (URL), and Account Manager (lookup to User).
Step 1: Enable Quick Create on the Vendor table. In make.powerapps.com, open your solution, find the Vendor table, open Settings, and check "Allow Quick Create." Save.
Step 2: Create the Quick Create form. Navigate to the Forms area of the Vendor table. Click "Add form" → "Quick create form." The form opens in the designer.
Step 3: Add fields to the form. From the Columns panel, drag these fields onto the canvas in this order: Vendor Name, Category, Primary Contact, Account Manager. Four fields is ideal. Vendor Name is required (you'll see it marked), so it must be there.
Step 4: Save and publish the form. Name the form "Vendor Quick Create," save, and publish. Verify in the Forms list that its status shows as Active.
Step 5: Test from a lookup. Go to a table that has a lookup to Vendor — perhaps a Purchase Order table. Open a Purchase Order record (or create a new one on the full Main form). Find the Vendor lookup field. Type a name that doesn't exist and look for the "+ New Vendor" option in the dropdown. Click it. The Quick Create form should appear as a right-side modal with your four fields.
Step 6: Test the fallback. Go back to the Vendor table's Forms list and deactivate your Quick Create form. Now repeat Step 5. You should be redirected to the full Vendor Main form instead of getting the modal. This confirms the fallback is working. Reactivate the form when done.
Bonus: Add the Vendor table to the app's global navigation with Quick Create enabled, then find it in the "+" menu in the nav bar.
"My Quick Create form isn't appearing from the lookup." Check all three: (1) Is Quick Create enabled on the Vendor table in its settings? (2) Is there an active Quick Create form? (3) Is Quick Create NOT disabled on the specific lookup field in the form designer? All three must be true.
"The form appears but required fields are blocking save." A column marked "Business Required" at the Dataverse level will be required everywhere — including Quick Create. If users can't complete the field quickly, you have two options: remove the business-required setting from the column and enforce it only on the Main form via a business rule, or add the field to the Quick Create form with a sensible default.
"Pre-population isn't working from a subgrid." Pre-population requires that the Quick Create form contains the lookup column that represents the relationship. If the parent-child lookup field isn't on the Quick Create form, Dataverse has nowhere to put the pre-populated value. Add the relationship lookup column to the form even if you want it to be read-only.
"The Quick Create form opened but after saving, the lookup didn't auto-populate." This usually means the fallback triggered instead — confirm the form is active and no fallback to Main form occurred. Also confirm the lookup field on the parent form didn't have Quick Create disabled.
"Users with certain security roles don't see the Quick Create form." Each Quick Create form is role-restricted. Go to the Forms list, select the Quick Create form, and check which security roles have access to it. Assign the appropriate roles.
Quick Create forms are one of the highest-leverage UX improvements you can make in a model-driven app. A few hours of configuration can save your users thousands of navigation interruptions per week. Here's what you've covered:
As a next step, consider pairing your Quick Create form configuration with well-designed views. The lookup dropdown that triggers Quick Create also uses a Lookup View to surface existing records — making sure that view is accurate and useful is equally important. Learn how to configure that in Configuring Model-Driven App Views as Default Views, Quick Find Views, and Lookup Views.
You might also explore how your Quick Create forms interact with the broader data model you've built. If you're working with complex multi-table relationships, Designing a Dataverse Data Model: Relationships, Lookups, and Choice Columns is a great companion to this lesson for thinking through which tables benefit most from Quick Create.
Model-Driven Apps & Dataverse