Configuring Model-Driven App Navigation Behavior for Lookup Columns: Controlling In-Line Editing, Lookup Dialog Filters, and Default Table Views on Form Fields

Introduction

Picture this: your sales team is filling out a new Opportunity record. They click the Account lookup field to find the customer. A dialog opens showing every single account in the system — including inactive customers from five years ago, internal test accounts, and subsidiaries they've never heard of. They scroll through hundreds of irrelevant options, pick the wrong one, and move on without noticing. The data quality problem compounds from there.

This is one of the most common and most fixable friction points in model-driven app design. Lookup columns — the fields that let users select a related record from another table — are incredibly powerful, but their out-of-the-box behavior is generic. By default, they show all records in the target table, use whatever the system's default view happens to be, and allow (or disallow) in-line editing based on global form settings. The good news is that every one of these behaviors is configurable, and you don't need to write a single line of code to control them.

By the end of this lesson, you'll know exactly how to shape the lookup experience on your forms — from filtering the available records down to only the ones that make sense in context, to specifying which view drives the lookup dialog, to controlling whether users can edit related record information directly on the parent form without navigating away.

What you'll learn:

• What lookup columns are and how they relate to Dataverse table relationships
• How to configure the default view that appears in the lookup dialog on a form field
• How to apply static and relationship-based filters to narrow the records shown in a lookup
• How to enable and configure in-line editing (quick create) behavior for lookup fields
• How to troubleshoot common lookup configuration problems before they reach users

---

Prerequisites

You should be comfortable with the basics of Dataverse tables and columns before diving into this lesson. If you're new to how tables relate to one another, Designing a Dataverse Data Model: Relationships, Lookups, and Choice Columns will give you the foundation you need. You should also have opened at least one model-driven app form in the form editor — if that's unfamiliar territory, Building Your First Model-Driven App: Site Map, Tables, Forms, and Views is a good starting point.

---

Understanding Lookup Columns on Forms

Before we configure anything, let's make sure we're aligned on what a lookup column actually is at the data layer.

A lookup column is a column on a Dataverse table that stores a reference to a single record in another table (or sometimes the same table). It's the visual face of a one-to-many relationship: when you have an Opportunity related to an Account, that relationship is surfaced on the Opportunity form as a lookup field pointing to the Account table. The field stores the Account's unique record identifier (a GUID), but it displays the Account's primary name column to the user.

When a user interacts with a lookup field on a form, they experience three distinct interactions:

1. Typing to search — the user starts typing and an auto-suggest dropdown appears showing matching records
2. Opening the lookup dialog — the user clicks the search icon to open a full dialog with a grid of records they can browse and filter
3. Navigating to the related record — the user clicks the value already populated in the field to open that related record in a new page

Each of these interactions is affected by the configuration choices you make on the form field. Understanding which interaction you're configuring — and why — is half the battle.

---

Navigating to Lookup Field Properties in the Form Editor

All the configuration we'll cover in this lesson lives in the form editor, specifically on the Field Properties panel for the lookup column. Here's how to get there.

Start by opening make.powerapps.com and navigating to your solution. From the solution explorer, find the table that contains your form (say, the Opportunity table), expand it, click Forms, and open the main form you want to edit.

Once you're in the form editor, click on the lookup field you want to configure. In the right-hand panel, you'll see a Field Properties section. At the bottom of that panel, look for a link labeled Field Properties or a gear/properties icon — clicking this opens a full properties dialog with multiple tabs. The tabs you'll work with are:

• Display — controls label, visibility, and locking behavior
• Details — shows the column schema name and data type
• Relationships — where lookup filter and view configuration lives (sometimes labeled differently depending on form editor version)

The classic form editor presents a tabbed dialog with a Relationships tab that exposes all the options we're about to explore. We'll describe both paths where they differ.

---

Controlling the Default View in the Lookup Dialog

When a user opens the lookup dialog — the full-screen grid that appears when they click the search icon — they see a grid of records. That grid is driven by a view defined on the target table. By default, Dataverse uses whatever is set as the lookup view for that table, but you can override this per field on a per-form basis.

This matters a lot. The default lookup view for the Account table, for example, might show Account Name, City, and Phone Number. But on your Service Contract form, you might want users to see Account Name, Industry, and Account Manager so they can make a more informed selection. You can specify exactly which view drives the lookup dialog for this particular field on this particular form.

How to Set the Default View

In the classic form editor, with the lookup field properties dialog open, click the Relationships tab. You'll see a dropdown labeled Default View. This dropdown lists all views defined on the target table. Select the view you want users to see when the lookup dialog opens for this field.

If you want to both set the default view and prevent users from switching to other views, check the checkbox labeled Disable view selector for this field (the exact label varies slightly by platform version). When this is checked, the view picker dropdown inside the lookup dialog is hidden, and users see only the records in the view you've specified. This is a powerful guardrail when you want to enforce data quality by limiting what's selectable.

Creating a Purpose-Built Lookup View

For complex apps, it's worth creating a view specifically intended for lookup use. Navigate to the target table, go to Views, and create a new view. Keep it focused: show only the columns that help users identify the right record quickly (name, type, status, owner — whatever fits your context). Then apply filters to that view to exclude records users shouldn't select (inactive records, for example).

You can learn more about building targeted views in Creating and Customizing Views in Model-Driven Apps: Filters, Sorting, and Editable Grids. The key difference with a lookup view is that you're optimizing for identification at a glance rather than bulk data review — keep the column count low and the most identifying information front and center.

---

Applying Filters to the Lookup Dialog

Setting the default view gets you partway there, but view-level filters are static — they filter based on column values in the target table. What if you need to filter the lookup based on values in the current record? That's where relationship-based filters come in.

Static Filters via View Definition

The simplest filtering approach is to bake the filter into the view itself. If you only ever want users to pick Active accounts, create a lookup view on the Account table with a filter of Status = Active. Assign that view as the default lookup view for your field. Done — users will never see inactive accounts in the dialog.

This approach is great when the filter condition is absolute and doesn't change based on context.

Dynamic Filters: Filtering by Related Fields

The more sophisticated option is to filter the lookup records based on values on the current form. This is configured in the Relationship filter section of the lookup field properties.

Here's a realistic example: you're building a Service Request form. It has a lookup to Account and a second lookup to Contact. You want the Contact lookup to show only contacts who belong to the Account already selected on the form. Without filtering, clicking the Contact lookup would show every contact in the entire system.

In the classic form editor's Relationships tab (with the lookup field properties dialog open), look for a section labeled Additional Filters or Relationship Filtering. You'll see an option to enable filtering and a field called Relationship where you pick which relationship between the target table (Contact) and another table on the form (Account) should be used to filter.

Concretely:

• Your Contact lookup on the Service Request form
• Target table: Contact
• Filter by: the Contact-to-Account relationship, using the value from the Account field already on this form

When this is configured, as soon as a user selects an Account, the Contact lookup will automatically scope its results to only contacts associated with that account. If no Account is selected yet, all contacts appear (or none, depending on how you configure the "show all records" option).

There's also a checkbox usually labeled Allow users to turn off the filter or Show records where relationship column has value — keep this unchecked if you want the filter to be mandatory. If you check it, users will see a toggle in the lookup dialog that lets them bypass the filter and see all records. That's sometimes the right call (for edge cases or admin overrides), but think carefully before enabling it in high-volume data entry flows.

---

Configuring In-Line Editing and Quick Create Behavior

Now let's talk about the other side of lookup UX: what happens when a user realizes the record they need doesn't exist yet.

By default, lookup fields in model-driven apps show a Quick Create option — a small "+" button next to the field. Clicking it opens a quick create panel (a simplified version of the target table's create form) without navigating away from the current record. The user fills in the minimum required fields, saves the new record, and the lookup is automatically populated with that newly created record.

This is called quick create or inline creation, and it's controlled by two separate settings: one at the table level, and one at the form field level.

Table-Level Quick Create Setting

For quick create to be available on a lookup field, the target table must have quick create enabled. Navigate to the target table's settings, open Advanced settings (sometimes under the Properties panel when the table is selected in the solution explorer), and verify that Allow quick create is checked.

If this is unchecked on the Account table, then no lookup pointing to Account will offer the "+" quick create button, regardless of what you configure on the form field. This is by design — table owners control whether their table can be quickly created from other contexts.

You should also ensure the target table has a Quick Create form defined. Quick create forms are a distinct form type — lighter weight than main forms, typically showing only the essential required fields. See Designing Model-Driven Forms: Sections, Tabs, Subgrids, and Quick View Forms for more on how quick create forms work alongside main forms.

Field-Level Quick Create Toggle

Even if the target table has quick create enabled, you can disable it for a specific field on a specific form. In the lookup field properties, look for a checkbox labeled Disable quick create (or in some versions, an option to control whether the create button appears). Check this to hide the "+" button for this particular field.

When would you do this? Consider a Vendor lookup on a Purchase Order form. You almost certainly don't want any purchasing clerk to create a new Vendor record on the fly while filling out a purchase order — Vendor creation should go through a vetting process. Disabling quick create on that specific lookup enforces that process without changing the global Vendor table settings.

In-Line Editing on Lookup Values

Separate from quick create, there's another behavior worth understanding: what happens when a user clicks on a populated lookup value? By default, clicking the value navigates the user to the related record in a full-page view. This is correct behavior in most scenarios — it lets users drill into the detail of a related record.

However, in some app designs, you might want to show a Quick View form embedded directly on the parent record instead, so users can see key fields from the related record without leaving the page. This isn't strictly "in-line editing" (quick view forms are read-only by default), but it creates a much smoother navigation experience.

The quick view form configuration lives not on the lookup field itself, but on a Quick View control that you add to the form separately. You can read more about that approach in Configuring Model-Driven App Quick Forms and Card Forms: Displaying Related Record Summaries in Lookups and Subgrids.

---

The Lookup View vs. the Default View: Clearing Up the Confusion

This is where many makers get tangled up, so let's separate two things that are easy to conflate.

Lookup views are defined at the table level and designated with the view type "Lookup View." Every table can have one designated lookup view, and by default, this is what appears in the lookup dialog for all lookup fields pointing to that table across your entire app.

Default view on a form field is a per-form, per-field override. It lets you specify a different view for the lookup dialog when users are on a specific form. This overrides the table-level lookup view.

So the hierarchy is:

1. Per-field override (highest priority, configured on the form)
2. Table-level lookup view (the designated lookup view on the target table)
3. The table's overall default view (fallback)

When you configure a default view in the lookup field properties dialog, you're setting option #1 in this hierarchy. If you leave it blank, the system falls back to #2.

If you want to understand how lookup views are designated at the table level, that's covered in detail in Configuring Model-Driven App Views as Default Views, Quick Find Views, and Lookup Views: Controlling How Records Are Surfaced Across the App.

---

Hands-On Exercise

Let's put this together with a practical scenario you can follow in your own environment.

Scenario: You have a Service Request table with two lookup fields: Account (which customer is making the request) and Primary Contact (the specific person at that account to coordinate with). You want to:

• Filter the Contact lookup to show only contacts associated with the selected Account
• Use a view called "Active Contacts - For Lookup" in the Contact lookup dialog
• Disable quick create on the Contact lookup (contacts should be managed separately)

Step 1: Create the lookup view on the Contact table (if it doesn't exist). Navigate to your solution, open the Contact table, go to Views, click New View, and name it "Active Contacts - For Lookup." Add columns: Full Name, Account Name, Job Title, Email. Apply a filter: Status = Active. Save and publish.

Step 2: Open the Service Request main form in the form editor. Click the Primary Contact lookup field.

Step 3: Open field properties. In the classic editor, right-click the field and choose Field Properties, then go to the Relationships tab.

Step 4: In the Default View dropdown, select "Active Contacts - For Lookup." Check Disable view selector if you want to prevent users from switching views.

Step 5: In the relationship filter section, enable the filter. Set the relationship to the Contact-Account relationship, and set the reference field to the Account field on the current form. This tells the system: "When the Account field has a value, show only contacts related to that account."

Step 6: Check the Disable quick create checkbox.

Step 7: Save and publish the form. Test by opening a Service Request record, selecting an Account, then clicking the Contact lookup — you should see only active contacts for that account.

---

Common Mistakes & Troubleshooting

"The relationship filter isn't working — it's still showing all contacts." First check: does the Contact table have a lookup column pointing to Account in your data model? The relationship filter depends on this link existing. If the relationship is missing, the filter silently does nothing. Second check: is the Account field on the same form populated? The filter only activates when the referenced field has a value.

"The default view I set isn't appearing in the lookup dialog." Verify the view is published. Views in draft state won't appear. Also check that the view is accessible to the security roles your users are in — if the view is defined but users don't have read access to the records it would show, the system may fall back to another view.

"The quick create button still appears even though I disabled it on the field." Make sure you saved and published the form after making the change. Unpublished form changes don't take effect. Also clear your browser cache — form changes sometimes require a hard refresh.

"Users can still bypass my lookup filter by typing in the search box." The relationship filter and default view settings apply to the lookup dialog (the grid popup), but the auto-suggest dropdown that appears when typing is driven by the Quick Find configuration on the target table, not the form-level filter. You'll need to look at Quick Find view configuration to control what appears in the type-ahead search. See Configuring Dataverse Search: Enabling Relevance Search, Configuring Searchable Tables and Columns, and Tuning Quick Find for Model-Driven Apps for how to tighten that up.

"My view isn't in the dropdown when configuring the default lookup view." Only views of the correct type for the target table will appear. If you created a Personal view rather than a System view, it won't be available for use as a default lookup view on a form — personal views are user-specific. Create a System view instead.

---

Summary & Next Steps

Lookup columns are the connective tissue of a model-driven app — they're how users navigate between related records and how related data gets linked together at the data layer. When left at their defaults, lookup fields are functional but generic. When you take ten minutes to configure the default view, apply relationship-based filters, and control quick create behavior, you transform them into focused, context-aware tools that guide users toward correct data entry.

The key things to take away:

• Default view on a form field overrides the table-level lookup view, letting you show the right columns for a specific context
• Relationship filters dynamically scope lookup options based on other values on the same form — powerful for reducing noise and preventing mismatches
• Quick create is controlled at two levels: the table (allow or disallow) and the form field (disable for a specific field even if the table allows it)
• The lookup dialog and the type-ahead search are configured separately — don't forget the Quick Find side of the equation
• These are all UX controls, not security controls — pair them with proper role configuration for true enforcement

From here, consider exploring how views are configured and designated at the table level in Configuring Model-Driven App Views as Default Views, Quick Find Views, and Lookup Views: Controlling How Records Are Surfaced Across the App. If you're building forms with more complex related-record display needs, Configuring Model-Driven App Quick Forms and Card Forms: Displaying Related Record Summaries in Lookups and Subgrids is the natural next step.