Most model-driven app problems aren't about missing features — they're about misconfigured views. Learn how to set Default Views, Quick Find Views, and Lookup Views so records are always findable, searchable, and presented with the right context wherever they appear in your app.
Imagine you've just deployed a model-driven app for your sales team. They open the Accounts table and immediately see 1,200 records sorted by the date they were created — ancient accounts mixed in with active ones, no filtering, no useful columns. Then they try to search for a customer named "Contoso" using the search bar, and nothing comes back. Later, a service rep tries to pick a contact from a lookup field on a case form, and the popup shows a two-column list with no phone number or email visible. Your users are frustrated, and you're fielding help desk tickets on day one.
Every one of those problems has the same root cause: views weren't configured intentionally. In a model-driven app, views are not just a cosmetic choice — they are the primary mechanism that controls how records are surfaced throughout the entire application. The default view determines what users see when they open a table. The Quick Find view determines which fields Dataverse searches through when someone types in the search box. The lookup view determines what records appear — and in what format — when users click a lookup field on a form. Getting these three view types right is one of the highest-leverage configuration decisions you can make for usability.
By the end of this lesson, you'll be able to configure each of these view types with precision and purpose. You'll understand why each one works the way it does, not just how to set it.
What you'll learn:
Before working through this lesson, you should be comfortable with the basics of Dataverse tables and the fundamentals of model-driven app structure. If you're new to how tables, columns, and rows work, start with Dataverse Fundamentals: Tables, Columns, and Rows Explained for Power Apps Makers. You should also have at least built or opened a model-driven app — Building Your First Model-Driven App: Site Map, Tables, Forms, and Views covers that ground well. Some familiarity with Creating and Customizing Views in Model-Driven Apps: Filters, Sorting, and Editable Grids will help you build and edit views before you configure their roles.
Before configuring anything, you need a solid mental model of what these three view types actually do. Think of a large office filing cabinet. The Default View is how that cabinet is organized when you first open the drawer — what folders are visible, in what order, and which ones are color-coded as important. The Quick Find View is the index card in the front of the cabinet that tells the office clerk which fields to look in when you ask "find me anything related to Contoso." The Lookup View is the window that pops open when someone says "which account should I attach this order to?" — it shows a curated, searchable list of records specifically sized for making a selection.
These three view types are not the only view types in Dataverse — there are also Associated Views, Advanced Find Views, and others — but these three are the ones that most directly shape the daily experience of every user in your app. Misconfiguring them is invisible to you as the maker but immediately painful to your users.
Key insight
Every table in Dataverse can have multiple views, but only certain views can hold certain roles. The Default Public View role can technically be applied to any public view, but only one view can hold that role at a time per table. The Quick Find View and Lookup View are each also singular — one of each per table, not per app.
When a user clicks a table in the navigation menu of your model-driven app, the first thing they see is the Default Public View for that table. This is the list grid that loads automatically — the columns it shows, the records it includes (based on its filter), and the order they're sorted.
A common misconception is that the "default" view is whatever view you happened to create first. That's not true. Dataverse ships with a system view called "Active [Table Name]" for most standard tables — for example, "Active Accounts" — and that view is the default out of the box. If you've built a custom view but never explicitly promoted it to the default, your users are still seeing Microsoft's generic view.
Here's how to designate a view as the default:
That's it. The view is now flagged as the Default Public View. You'll notice the view list shows a small indicator marking it as the default. The previous default view is automatically demoted — there can only be one default at a time.
The default view should answer the question: "What records does the typical user need to see right now?" For most business scenarios, that means:
Tip
If your organization has users with different roles who need to see different records by default, consider building separate model-driven apps for each persona and setting different default views in each app's table configuration. Within a single app, you can also control which views appear in the view selector dropdown by editing the app's table configuration in the app designer.
The Quick Find View is arguably the most misunderstood view type. It doesn't control what columns are displayed in results — at least not primarily. Its real job is to define which fields Dataverse searches through when a user types in the search box at the top of a table's list page.
When a user types "Contoso" into the search bar on the Accounts table, Dataverse uses the Quick Find View's Find Columns to determine where to look. If "Account Name" is in the Find Columns list but "Website" and "Email" are not, then searching for a domain name like "contoso.com" will return nothing — even if every account in the database has that domain in its Website field.
The Quick Find View has two distinct parts that many beginners confuse:
This distinction is critical. You could have a Quick Find View that displays Account Name, City, and Phone — but searches through Account Name, Email, Phone, and Website. The user sees a clean three-column result but the search itself is casting a wide net.
Warning
There is a platform limit on how many find columns you can include — Dataverse won't let you add every column in the table. Stick to the columns users are actually likely to search by. Over-indexing Quick Find Views with dozens of columns can also slow search performance for large tables.
Suppose you're managing a table called Work Order with columns: Work Order Number, Customer Name, Site Address, Description, Status, and Assigned Technician.
A technician in the field searches for a work order by typing a partial site address. If "Site Address" isn't in your Quick Find View's find columns, that search returns nothing. The technician assumes the record doesn't exist, creates a duplicate, and now you have a data quality problem. Adding "Site Address" to the find columns takes thirty seconds and prevents that entire scenario.
Note
Quick Find View search is also what powers the search box in Relevance Search (now called Dataverse Search) when configured. However, Dataverse Search has its own indexing and may search more broadly. The Quick Find View specifically controls the "search this view" behavior on the table's list page. Understanding which search mechanism is active in your app matters — check your app settings under Advanced Settings to confirm whether Dataverse Search or Quick Find is the active search mode.
The Lookup View controls what users see when they click a lookup field on a form and a dialog opens for them to select a related record. This is a completely different surface than the table's main list page.
Consider a Case form that has a lookup field pointing to the Contact table. When a support agent clicks that field to find a customer, a small dialog opens showing a list of Contacts. What columns does that dialog show? How are records sorted? What's the default search behavior? All of that is controlled by the Lookup View of the Contact table.
The Lookup View is often neglected entirely, leaving users with the system default — which typically shows just the record name and nothing else. That forces agents to search blind, unable to distinguish between two "John Smith" records without additional context like email or phone number.
Tip
The Lookup View is shared across all lookup fields that point to that table, across all apps in your environment. If you have a lookup to Contact on your Case form, your Work Order form, and your Opportunity form, they will all use the same Contact Lookup View. Design it to be universally useful rather than hyper-specific to one scenario.
When a user types in the search box inside a lookup dialog, that search uses the Quick Find View's find columns of the target table — not any configuration of the Lookup View itself. This is an important connection: the Lookup View controls display, and the Quick Find View controls searchability, even inside lookup dialogs. Both views need to be well-configured for a good lookup experience.
This is why a user can see three columns in a lookup dialog (Lookup View) but can search across six fields (Quick Find find columns). The two work in tandem.
Key insight
If users complain that they can't find records when typing in a lookup field, the problem is almost certainly in the Quick Find View's find columns — not in the Lookup View. If users can find records but the results look unhelpful (just names, no context), the problem is in the Lookup View's display columns.
There's an important layer of control above the view-type configuration: the model-driven app designer itself. When you add a table to a model-driven app, you can control which views are exposed to users of that specific app. Users only see the views you've enabled.
To configure this:
This does not change which view is the default — that's still controlled at the table level. But it does mean users can't manually switch to a view that's inappropriate for their workflow. For example, if you have an internal "Audit: All Records Including Deleted" view that's meant only for administrators, you can exclude it from end-user apps while still leaving it available in the Power Apps maker portal.
This app-level control is especially important when your Dataverse environment serves multiple apps with different user personas. As you think about model-driven app security and role-based access, remember that hiding a view from an app is a usability control, not a security control. A user can still access hidden views through Advanced Find or direct URL navigation unless you've restricted their security role appropriately.
Let's put this into practice with a realistic scenario. You have a model-driven app for a field service company. The Work Order table has these columns: Work Order Number, Customer (lookup to Account), Site Address, Scheduled Date, Status, Priority, and Assigned Technician.
Step 1: Create and set a Default View
Create a new view called "Open Work Orders – This Week" with the following configuration:
Save the view, then use the context menu to set it as the default view. Confirm by navigating to the Work Order table list in your app — this view should load automatically.
Step 2: Configure the Quick Find View
Open the Quick Find View for the Work Order table. Ensure the display columns include Work Order Number, Customer, and Scheduled Date. Then open the Find Columns configuration and add: Work Order Number, Customer, Site Address, and Assigned Technician (the name field). Save and publish.
Test by typing a partial site address in the search box on the Work Orders list page. If configured correctly, matching records should appear.
Step 3: Improve the Lookup View on Account
Since Work Orders have a lookup to Account, open the Account table and edit its Lookup View. Add columns: Account Name, Phone, City, Account Number. Sort by Account Name ascending. Save and publish.
Now open a Work Order record or create a new one. Click the Customer lookup field. The dialog that opens should show all four columns, making it easy to distinguish between accounts with similar names.
Step 4: Verify the connection
On that same lookup dialog, type a partial account name in the search box. Note that it searches — then deliberately type something that's only in the Phone or City column of an Account. If it doesn't find anything, open the Account Quick Find View and add Phone and City to the find columns. Test again.
Problem: Users say "the search doesn't find anything" on the list page. Cause: The Quick Find View's find columns don't include the fields users are searching by. Fix: Open the Quick Find View, click Add Find Columns, and add the relevant fields. Publish.
Problem: The lookup dialog shows records users shouldn't be selecting (e.g., inactive contacts). Cause: The Lookup View has no filter on Status. Fix: Edit the Lookup View and add a filter condition: Status = Active. Publish.
Problem: After setting a new default view, users still see the old view. Cause: The app has been published but not refreshed, or the browser cached the old state. Also verify the view was actually flagged as default at the table level, not just added to the app. Fix: Clear browser cache or use Ctrl+Shift+R to force refresh. Re-confirm the default flag in the table's Views tab.
Problem: A custom view isn't appearing in the view selector dropdown for users. Cause: The view was saved but not published, or it's not enabled in the app designer. Fix: Open the table's Views tab and confirm the view's state is "Published." Then check the app designer and enable that view for the app.
Problem: The lookup dialog looks completely different than expected. Cause: A lookup field can be configured to use a specific view rather than the default Lookup View. This is done in the form editor's field properties. Fix: Open the form in the form editor, click the lookup field, and look in its properties for "Related Records Filter" or view override settings. If a specific view has been hardcoded, either adjust that view or clear the override.
Warning
Changes to views — especially the Quick Find View and Lookup View — apply across your entire environment, not just your specific app. If multiple apps use the same Dataverse table (which is common), a change to the Account Lookup View affects every app that has a lookup to Account. Always test changes in a non-production environment first, or at minimum, communicate changes to other app owners.
Views in model-driven apps are load-bearing infrastructure, not decoration. The Default Public View determines the first impression every user gets when they open a table. The Quick Find View determines the intelligence behind every search interaction — it's the index that makes records findable or invisible. The Lookup View determines the quality of the selection experience every time a user links a record to another through a lookup field. These three view types work together across every surface of your app, and getting them right is the difference between an app that feels fast and intuitive and one that generates a support ticket on day one.
Configuring these views well requires you to think like your users: What are they looking for? What information do they need to identify the right record? What's the most common way they'll search? Answer those questions, and you'll know exactly what to put in each view.
From here, a natural next step is deepening your knowledge of view construction itself — Creating and Customizing Views in Model-Driven Apps: Filters, Sorting, and Editable Grids goes deep on advanced filtering and editable grid configuration. If you're thinking about how your Dataverse data model affects which lookup views exist and how they connect, Designing a Dataverse Data Model: Relationships, Lookups, and Choice Columns provides the structural foundation. And if you want to think carefully about how security roles interact with view visibility, Model-Driven App Security: Configuring Security Roles, Field Permissions, and Team-Based Access for Table Data is the right companion lesson.