Quick Create forms and Card forms solve two of the most common friction points in model-driven apps — slow cross-record data entry and cluttered mobile layouts. This lesson teaches you how to build, configure, and troubleshoot both form types with a realistic field service scenario.
Picture this: your sales team is entering a new opportunity in your model-driven app, and they need to associate it with a contact. They click the lookup field to search for the contact, realize the person doesn't exist yet, and now they have to abandon what they were doing, navigate to the Contacts table, create a full record with every field the main form demands, save it, navigate back to Opportunities, and start over. The whole process takes three minutes for something that should take thirty seconds.
Or picture your field technicians trying to log a service request on their phones. The main form loads with twelve tabs, collapsing columns, and forty fields — most of which they don't need in the field. The form is technically responsive, but it's a frustrating experience compared to a purpose-built mobile layout.
These are the exact problems that Quick Create forms and Card forms solve. Quick Create forms give users a minimal, focused dialog for creating records on the fly without leaving their current context. Card forms provide a compact, scannable layout designed for mobile use and the new Unified Interface card views. By the end of this lesson, you'll know how both form types work, when each is appropriate, and how to build and configure them properly — including the details that catch most beginners off guard.
What you'll learn:
You should be comfortable with the basics of Dataverse tables and how model-driven apps are structured before tackling this lesson. If you haven't built a model-driven app yet, work through Building Your First Model-Driven App: Site Map, Tables, Forms, and Views first. You should also have a basic understanding of Dataverse Fundamentals: Tables, Columns, and Rows Explained for Power Apps Makers and how forms are generally structured from Designing Model-Driven Forms: Sections, Tabs, Subgrids, and Quick View Forms.
A Quick Create form is a special form type that renders as a side panel or dialog — not a full page. It appears in two key situations:
+ icon at the top of the app) to quickly add a record without leaving their current screen.The form deliberately shows only a handful of fields — typically four to eight — because the intent is speed. The user answers the critical questions, saves, and the new record is immediately selected or available. Everything else can be filled in later.
Key insight
Quick Create forms don't replace your main form. They're a fast path to create a record with minimum viable data. Users can always open the full record afterward to complete the rest of the fields.
This distinction matters for design. When you build a Quick Create form, you're not shrinking your main form — you're answering a different question: "What is the bare minimum a user needs to provide to make this record useful right now?"
A Card form is a different animal. It controls how a record appears inside a card view — a list view style in the Unified Interface that shows records as visual cards rather than table rows. Card views are the default presentation in certain mobile scenarios and can be selected as the view type when configuring views.
In a card layout, each record shows a small block with a title, a couple of supporting fields, and sometimes an image or icon. The Card form defines which fields fill those slots.
Think of it like the difference between a spreadsheet row (a standard view) and a business card (a card view). The Card form is the template for that business card.
Note
Card forms are most relevant when you've configured a view to use the Card layout type, or when your app is being used on mobile where card-style layouts are more readable. If none of your views use card layout and your users are all desktop-based, Card forms have limited immediate impact — but it's still worth configuring them correctly for future-proofing.
For this lesson, we'll use a realistic scenario: a Field Service data model with a Work Orders table and a Service Accounts table. When technicians are creating a work order, they often need to create a new service account on the fly. We'll build a Quick Create form for Service Accounts that makes this effortless. We'll also build a Card form for Work Orders so that the mobile view gives technicians the most relevant at-a-glance information.
Your Service Accounts table has columns like:
For our Quick Create form, we'll expose only: Account Name, Account Type, Primary Contact, and Address. That's enough to create a meaningful record without overwhelming the technician.
Before you build the form, you need to tell Dataverse that the table supports Quick Create. This is a table-level setting, and it's the number one thing people miss.
Navigate to make.powerapps.com and go to Tables in the left panel. Find your Service Accounts table and click into it. Click Properties (or Edit table properties depending on your interface). In the properties panel, look for the section labeled More options or expand the advanced options area. You'll find a checkbox labeled Allow quick create. Enable it and save.
Warning
If you skip this step, your Quick Create form will exist in the system but will never appear. No error, no warning — the lookup dialog will simply not show a "New" option, or the Quick Create button in the nav bar won't include your table. This is the most common reason people think Quick Create forms "don't work."
For standard Dataverse tables like Contact and Account, this setting is already enabled. For custom tables you create yourself, it defaults to off.
Now that the table is configured, open the form editor. From the table detail page, go to Forms and click New form. In the dialog that appears, select Quick Create as the form type. Give it a descriptive name — something like "Service Account Quick Create."
The form editor opens to a stripped-down canvas. Notice a few important differences from the main form editor:
These constraints are intentional. The dialog that renders this form has fixed dimensions, and complexity would defeat the purpose.
Click Add field (or drag from the column panel) to add your chosen columns. For our Service Accounts Quick Create, add in this order:
Keep the layout to two columns if you have four or more fields — it reduces vertical scrolling inside the dialog. For two fields, one column is fine.
Tip
Don't add required fields you can't reasonably expect a user to fill in during a quick create action. If "Contract Level" is required on the main form, consider making it optional at the table level (not required via column definition) and using a business rule on the main form scope only to enforce it there. Quick Create forms can't run main-form-scoped rules.
Order fields in the way a person naturally thinks through creating the record. For a service account: What is it? (Name) → What kind? (Type) → Who's the contact? (Primary Contact) → Where is it? (Address). This flows like filling out a form clipboard — a natural left-to-right, top-to-bottom cognitive path.
Once you've placed your fields, click Save and then Publish. Publishing is what makes the form live. A saved-but-unpublished form won't appear in the app.
Note
After publishing, it may take a minute or two for the form to appear in your app, especially if you're working in a production environment with multiple users. In development, a browser refresh usually does it.
One detail many beginners miss: if a table has multiple Quick Create forms (perhaps different teams need different sets of fields), you control which one is shown using form order. In the Forms list for your table, click the Form Order option in the top menu. You'll see a panel to arrange your Quick Create forms. The top-most active form in the list is what users see.
You can also mark a Quick Create form as Active or Inactive. Inactive forms don't appear in any context, so if you're deprecating an old form, set it inactive rather than deleting it — deletion is permanent and can't be undone if something references that form.
The best way to test is directly in your app. Open your model-driven app, navigate to a Work Order record, and click on a lookup field that points to Service Accounts. In the lookup dropdown, click New (you'll see a + button next to the search box, or a "New Service Account" option). The Quick Create dialog should slide in from the right with your four fields.
Fill in the fields, click Save and Close, and the new record should be immediately selected in the lookup. That's the full user journey in about fifteen seconds.
Also test the global Quick Create: click the + button in the top navigation bar. Your Service Accounts table should appear in the list of tables available for quick creation (because you enabled Allow quick create earlier).
Now let's shift to Card forms. Navigate to the Work Orders table, go to Forms, and click New form → Card. Name it "Work Order Card."
The Card form editor looks even simpler than Quick Create. You're working with a highly constrained canvas that maps to three zones:
For Work Orders, here's a sensible mapping:
This gives a technician everything they need at a glance: Which job? → For who? → What's the status? → When?
Key insight
Card forms are read-only in the card view itself. Users tap or click a card to open the full main form. So don't agonize over whether users can "edit" from the card — they can't. Focus purely on what information helps them identify and prioritize records.
In the Card form editor, you'll see slots for each of these zones. Drag or assign columns to each slot. Save and publish when done.
Building the Card form is only half the job. You need a view configured to use the card layout for the Card form to matter. This connects to the broader topic covered in Creating and Customizing Views in Model-Driven Apps: Filters, Sorting, and Editable Grids.
In the Work Orders table, go to Views and either edit an existing view or create a new one. Inside the view editor, look for the Properties panel or the view settings. There should be a Style or Type option. Change it to Card (rather than the default Read-only grid or Editable grid).
Once a view is set to Card style, it uses the Card form associated with the table. If you have multiple Card forms, the one with the highest priority in the form order is used. If no Card form exists and the view is set to Card style, Dataverse falls back to showing just the primary name field — which is why building the form properly matters.
Warning
Not all view types support card style. The Card style option is most relevant for views in the Unified Interface and mobile. If you set a view to Card style but use it in a context that doesn't support it, it may fall back to the standard grid. Always test on the target device type.
Quick Create forms interact directly with table relationships and lookup columns. When a Quick Create form is triggered from a lookup field on another form, Dataverse automatically pre-filters which Quick Create form to show based on the target table of that lookup column.
For example, if you have both a "Service Account" Quick Create form and a "Vendor Account" Quick Create form on an Accounts table (distinguished by some form logic), the lookup field's configuration determines what the user sees. This ties into how lookup views are configured — the lookup view controls the search results, while the Quick Create form controls the creation dialog.
If your table uses polymorphic lookups (lookups that can point to multiple tables), each target table needs its own Quick Create form enabled. See Configuring Dataverse Polymorphic Lookups and Customer Columns for how that works at the relationship level.
Work through this exercise in your own Power Apps environment. If you don't have one, a free developer environment at make.powerapps.com works fine.
Scenario: You have a simple Projects table and a Clients table. The Projects table has a lookup to Clients.
Step 1 — Enable Quick Create on Clients:
Step 2 — Create the Quick Create Form:
Step 3 — Test in context:
Step 4 — Create the Card Form for Projects:
Step 5 — Configure a view to use Card style:
Step 6 — Verify:
Problem: Quick Create form doesn't appear in the lookup dialog. Cause: Either "Allow quick create" is not enabled on the table, or the form hasn't been published. Fix: Check both. Republish the form and reload the app.
Problem: Quick Create form appears but then shows a validation error about required fields. Cause: A column is marked required at the column level (not just on the form), and that required column isn't included in your Quick Create form. Dataverse still enforces column-level requirements even on Quick Create. Fix: Either add the required field to the Quick Create form, set a default value on the column, or relax the requirement to "Business Recommended" rather than "Business Required" at the column level if the field isn't truly always needed at creation time.
Problem: Card form fields are showing but the layout looks wrong on mobile. Cause: The view isn't set to Card style, so the Card form isn't being used. Fix: Edit the view and explicitly set the style to Card.
Problem: Quick Create form has too many steps and users are complaining. Cause: You've added too many fields, some of which are lookup fields that require their own sub-searches. Fix: Ruthlessly prune the form. Three to five fields is ideal. If a field requires context that the user doesn't have in the moment of quick creation, it doesn't belong here.
Problem: Quick Create form runs a business rule that references a field not on the form. Cause: Business rules set to "Entity scope" run regardless of which form is active, including Quick Create. If the rule references a field that isn't on the Quick Create form, the rule condition may always evaluate to false or always true. Fix: Set business rules that reference form-specific fields to "Form scope" so they only run on the main form. Use Entity scope rules only for logic that should run universally.
Tip
When troubleshooting forms, always check the Published status in the Forms list. The column shows whether a form is Published or in a draft/unpublished state. If it says "Draft," nothing you've done is live yet.
Quick Create forms and Card forms solve two specific usability problems in model-driven apps: they reduce friction in cross-record data entry and improve readability in compact layouts. Neither form type replaces your main form — they complement it by serving different user contexts.
Here's what to remember:
From here, you have several natural directions to explore. If you want to understand how to control which records appear when users search in a lookup dialog, dig into Configuring Model-Driven App Views as Default Views, Quick Find Views, and Lookup Views. If you want to automate validation and field logic that works across form types including Quick Create, explore Business Rules in Dataverse: Validation and Field Logic Without Code. And if you're building out the broader data model that makes these lookups meaningful, Configuring Dataverse Table Relationships in Model-Driven Apps is the right next stop.