Most Dataverse Search problems aren't data problems — they're configuration problems. This lesson teaches you exactly how to enable Dataverse Search, control which tables and columns are indexed, and tune Quick Find views so users actually find what they're looking for.
Picture this: your sales team is using a model-driven app to manage thousands of accounts, contacts, and opportunities. A rep gets a call from a client and types the company name into the search bar. The spinner spins. Nothing useful comes back. They try a partial name. Still garbage. They give up and ask a colleague to find the record manually. This is a search failure — and it happens more often than it should in Power Apps deployments.
The problem is almost never the data. It's the search configuration. Dataverse ships with a capable, Azure Cognitive Search-powered engine called Dataverse Search (formerly Relevance Search), but it doesn't configure itself. Out of the box, many organizations are still running the older, slower Quick Find engine — or have Dataverse Search enabled but with so few tables and columns indexed that it barely outperforms guessing. Getting search right transforms how users experience your app every single day.
By the end of this lesson, you'll be able to make confident, deliberate decisions about every layer of Dataverse search: enabling and scoping Dataverse Search at the environment level, controlling which tables and columns are included in the search index, optimizing Quick Find views so both search engines return meaningful results, and avoiding the common configuration traps that leave search feeling broken even when everything is technically "on."
What you'll learn:
This lesson assumes you're comfortable working inside the Power Apps maker portal and have experience customizing tables, views, and columns in Dataverse. If you need a refresher on how Dataverse structures data, revisit Dataverse Fundamentals: Tables, Columns, and Rows Explained for Power Apps Makers. You should also understand how views work in model-driven apps — particularly Quick Find views — because they sit at the intersection of both search engines. If views are new territory, Creating and Customizing Views in Model-Driven Apps: Filters, Sorting, and Editable Grids will get you up to speed.
You'll need a System Administrator or System Customizer role to follow the configuration steps in this lesson.
Before you touch a single setting, you need to understand the architecture you're configuring. Dataverse doesn't have one search engine — it has two, and they operate at different scopes with different performance profiles.
Quick Find is the older engine. When a user types into the search box on a view grid (the search box directly above a list of records), Quick Find runs a LIKE '%searchterm%' style query against the Dataverse SQL layer. It checks the columns you've configured in the Quick Find view for that table.
This query is synchronous, runs against the live database, and scales poorly with large datasets. It also only searches one table at a time — whichever table's view is currently on screen. If you're looking at the Accounts grid and type "Contoso," it looks for Contoso in Accounts. Full stop.
Quick Find has one legitimately useful mode: the Lookup dialog. When users click on a lookup field to find a related record, Quick Find is what powers that search. This makes Quick Find view configuration still critically important even if you've enabled Dataverse Search.
Dataverse Search is backed by Azure Cognitive Search. Microsoft maintains a search index that replicates your Dataverse data and updates it incrementally (with a delay — more on that shortly). When a user types into the global search bar at the top of a model-driven app, Dataverse Search is what runs — if you've enabled it.
The key difference is scope: Dataverse Search can search across all indexed tables simultaneously and return ranked, relevance-scored results. A rep who types "Contoso" gets back matching accounts, contacts at Contoso, open opportunities tied to Contoso, and any service cases mentioning the name — all in one result set.
Key insight
Quick Find and Dataverse Search are not mutually exclusive. Enabling Dataverse Search replaces the global search bar behavior but Quick Find continues to power per-table grid search and all lookup dialogs. You need both configured properly.
When Dataverse Search is enabled, the global search bar shows a single unified result set by default. But there's a setting called Categorized Search that instead groups results by table — presenting Accounts results, then Contacts results, then Opportunities results in separate buckets. Microsoft deprecated the old Categorized Search mode in favor of unified results, and most current environments default to the unified experience. Know that the "single search box at the top" always uses whichever engine you've enabled at the environment level.
Dataverse Search is an environment-wide setting. You enable it once per environment, and it applies to all model-driven apps in that environment.
Go to admin.powerplatform.microsoft.com and select your target environment. Choose Settings from the top menu, then expand Product and click Features.
Scroll to the Search section. You'll find a toggle labeled Dataverse Search. Flip it on and save.
Warning
Enabling Dataverse Search for the first time triggers a full initial index build. For environments with large data volumes — tens of millions of records across many tables — this can take hours to days. Users won't see stale or missing results during this window; they'll see results that become progressively more complete as the index builds. Plan your initial enablement accordingly, and don't enable it at 9 AM on a Monday and then wonder why search is incomplete all morning.
In the same Features section, you may see a Copilot or AI-related search toggle. In newer environments, Dataverse Search is a prerequisite for Copilot features inside model-driven apps. If your organization plans to use any AI-assisted features, enabling Dataverse Search now avoids a disruptive re-enablement later.
When you first enable Dataverse Search, Microsoft automatically adds a default set of tables to the index. These are the standard system tables that most organizations use: Account, Contact, Lead, Opportunity, Case, Activity (Email, Phone Call, Task, Appointment), and a handful of others.
Here's the catch: custom tables are not automatically indexed. If you've built a custom Project, Inspection, or ServiceRequest table, it won't appear in search results until you explicitly configure it. This is the single most common reason users report that "search doesn't work" after Dataverse Search is enabled — they're searching for records in tables that aren't in the index at all.
Table-level search configuration controls which tables contribute records to Dataverse Search results. You manage this through the Power Apps maker portal, not the admin center.
Navigate to make.powerapps.com, select your environment, and go to Tables in the left nav. There's a dedicated path for this: click the ... (more options) menu or use the top navigation to find Advanced settings, then locate Configure Dataverse Search — or more specifically, open any table you want to configure and look at its Search properties.
The more reliable path is: from the left navigation, choose Tables, then in the command bar at the top, look for the Dataverse search option, which opens a pane showing all tables and their index status.
Alternatively, in some versions of the maker experience, you navigate to Settings > Advanced settings from the environment switcher, which opens the classic Dynamics 365 settings panel. From there: Settings > Customizations > Customize the System, then expand the Entity (table) and look at the General tab for the Appears in search results checkbox.
Note
Microsoft has been progressively migrating these settings into the modern maker portal. Depending on when you're reading this, the exact UI path may look slightly different, but the underlying setting — whether a table participates in Dataverse Search — remains the same. If you can't find it in one interface, try the other.
Let's use a concrete example: you've built a cr123_inspection table to track field inspections for a utilities company. Inspectors and dispatchers need to search inspections by address, asset ID, or inspector name. Here's how you add it:
Inspection)Once you've enabled the table, it will be added to the search index queue. Index propagation for a newly added table typically takes 15–30 minutes for moderate data volumes, though it can stretch longer for tables with hundreds of thousands of records.
You can also remove tables from search. This is useful when:
ZipCode reference table with 40,000 rows) that clutters search results users never want to seeKey insight
Dataverse Search respects security roles. A user will only see search results for records they have read access to according to their security role configuration. Removing a table from search is a usability decision, not a security backstop — don't rely on search exclusion to protect sensitive data.
Enabling a table for search is only the first step. The second, often overlooked step is controlling which columns within that table are indexed. This matters for two reasons: relevance quality and index size performance.
By default, Dataverse Search indexes a modest set of columns for each table: the primary name column, and columns you've added to the table's Quick Find view as "Find Columns." This means your Quick Find view configuration does double-duty — it controls both the per-table grid search AND contributes to what Dataverse Search indexes.
This is an important architectural detail. The Quick Find view has two distinct parts:
Navigate to your table's views, open the Quick Find view (every table has exactly one), and click Add find columns (or the equivalent in your version of the UI) to add columns that should be searchable.
For the Inspection table example, good candidates for indexing include:
cr123_address (text) — location where the inspection occurredcr123_assetid (text) — the utility asset being inspectedcr123_inspectornotes (multiline text) — descriptive notescr123_workordernumber (text) — the reference number field staff use to communicatePoor candidates include:
cr123_scheduleddate (date) — dates aren't searched as text; use filtered views insteadcr123_statusreason (choice) — choices are indexed, but users rarely type choice label text; filter views work bettercr123_latitude / cr123_longitude (decimal) — numeric geographic fields have no business being in a text search indexTip
When in doubt about whether a column should be searchable, ask: "Would a real user ever type this value into a search box expecting to find a record?" If the answer is no, leave it out. Over-indexing columns you don't need bloats the index, slows down searches, and produces irrelevant results.
Not every column type can be added as a search column. Dataverse Search can index:
Dataverse Search cannot index:
This is a common point of confusion. A column named CustomerID might store what looks like a text identifier, but if it's typed as Whole Number, it cannot be searched. In this case, you'd need either a calculated text column that mirrors the number, or you'd re-examine the column type. Check out Configuring Model-Driven App Column Properties: Data Types, Required Fields, and Display Settings for Dataverse Tables if you're weighing a column type change.
When you add a lookup column as a find column, Dataverse Search indexes the display name of the related record — not the GUID. So if your Inspection table has a lookup to Account, and an account is named "Pacific Gas and Electric," searching "Pacific Gas" will match inspections linked to that account. This is powerful behavior, but it means the linked table's primary name field needs to be meaningful, not an auto-generated code.
Even with Dataverse Search enabled, Quick Find views remain critical for two scenarios: per-table grid search (the search box directly above a view) and lookup dialog search (when users search for records to populate a lookup field). Both of these use Quick Find, regardless of your Dataverse Search settings.
Every table in Dataverse has a Quick Find system view. You can find it in the Views section of any table — it's labeled "Quick Find Active [TableName]" by convention. This view has three configurable pieces:
Warning
A very common mistake is confusing Find Columns with Display Columns in the Quick Find view editor. Adding a column to the display columns makes it visible in results, but doesn't make it searchable. Adding it to find columns makes it searchable but doesn't necessarily show it in results. You often want both — add important columns to both lists.
Let's walk through a realistic Quick Find configuration for the Inspection table. Open the Quick Find view for Inspection in the maker portal. In the right panel, you'll see the Find by section.
Click Add find columns and add:
Address (cr123_address)Asset ID (cr123_assetid)Work Order Number (cr123_workordernumber)Inspector (the lookup to the SystemUser or Contact table)For Display columns, configure the view to show:
With this setup, a dispatcher who types "WO-2024-0391" will find the matching inspection immediately. An inspector who types their colleague's name will see all inspections assigned to that person. The result list shows enough context (address, status, date) to pick the right record without opening it.
This is where Quick Find tuning has the biggest daily impact on user experience. When a user clicks a lookup field — say, selecting an Account on an Opportunity — they get a search dialog. That dialog uses the Account table's Quick Find view.
If the Account Quick Find view only searches the name column, a user who types "555-1234" expecting to find the account by phone number gets nothing. If you add telephone1 (Main Phone) to the Account Quick Find find columns, that search suddenly works.
For the Account table in a typical B2B scenario, good find columns are:
name (Account Name — always included by default)accountnumber (Account Number)telephone1 (Main Phone)emailaddress1 (Email)address1_city (City — useful for disambiguating common company names)For the Contact table in a customer service scenario:
fullname (always included)emailaddress1 (Email)mobilephone (Mobile Phone)telephone1 (Business Phone)parentcustomerid (Account — the lookup, so users can type the company name)Tip
Talk to the people who actually use the app before deciding what to make searchable. Dispatchers search differently than account managers. Salespeople search by company name; support agents search by ticket number or phone number. Your Quick Find configuration should reflect how humans actually think about finding records, not how the data model is organized.
Quick Find runs synchronous database queries. Adding too many find columns expands the query surface and can noticeably slow down lookup dialogs, especially for tables with millions of records. The general guidance:
LIKE '%term%' query on memo fields is extremely expensiveFor high-volume tables, Dataverse Search is a much better engine for free-text searching memo fields precisely because it uses an inverted index rather than a full-table scan.
One of the most common sources of user confusion with Dataverse Search is the sync delay. Unlike Quick Find, which queries live data, Dataverse Search queries an index that's updated asynchronously by Microsoft's indexing service.
In normal operation, the Dataverse Search index lags behind live data by a few minutes to about 15 minutes for most updates. New records, updated records, and deleted records all propagate to the index within this window under normal conditions.
However, several situations can extend this delay:
Key insight
If a user creates a new record and immediately searches for it in global search and can't find it, this is expected behavior. The record exists in Dataverse; it just hasn't been indexed yet. Train users that global search has a short propagation delay, and that the per-table view (which uses live data) is the right place to find records created in the last few minutes.
There's no native UI in Power Apps that shows you "this record has been indexed / this record has not been indexed." The best diagnostic approach is to check whether a newly created or modified record appears in search after 30 minutes. If it doesn't, escalate to Microsoft support — the indexing service itself may be experiencing issues.
For tables that were recently added to search, you can validate coverage by searching for records you know exist using unique text values. If those values return results, the index is populated.
Let's put all of this together with a realistic scenario. You're building a project management app for an engineering firm. The environment has these custom tables:
Project (with columns: Project Name, Project Code, Client Account lookup, Project Manager lookup, Description, Status)Milestone (with columns: Milestone Name, Project lookup, Due Date, Completion Notes)Issue (with columns: Issue Title, Project lookup, Reported By lookup, Description, Priority, Resolution Notes)Here's your complete search configuration plan:
In the Power Platform Admin Center, enable Dataverse Search for the environment. Confirm with your team that a 30-minute window of incomplete search results is acceptable before you do this during business hours.
Enable all three custom tables — Project, Milestone, and Issue — for search. Also confirm that Account and Contact are already in the index (they should be by default).
Project table Quick Find:
cr_projectname, cr_projectcode, cr_clientaccount (lookup), cr_projectmanager (lookup), cr_descriptionMilestone table Quick Find:
cr_milestonename, cr_completionnotesIssue table Quick Find:
cr_issuetitle, cr_description, cr_resolutionnotesDo not add Due Date, Priority (choice), or Status (choice) to find columns. These are filter-oriented fields, not text-search fields.
After 30–45 minutes, open the model-driven app and test these searches from the global search bar:
If any of these fail after waiting for index propagation, double-check that the relevant column is actually in the Find Columns of the Quick Find view, not just the Display Columns. This is the #1 diagnostic step.
On the Issue form, click the Project lookup field and type a partial project name. Verify it returns matching projects. If it doesn't, the Project table's Quick Find find columns aren't configured correctly, or the column you're searching isn't included.
Similarly, test the Reported By lookup (which links to a Contact or User). Type a first name — it should return matching contacts/users.
Most likely cause: The table isn't enabled for Dataverse Search, or the column with the search text isn't in the Quick Find find columns.
Diagnosis:
Cause: Too many find columns, or a find column is a long multiline text field.
Fix: Reduce find columns to the 3–5 most valuable fields. Move multiline text fields (Description, Notes) to Dataverse Search only — remove them from Quick Find find columns. Users searching by keyword phrase should use the global search bar, which uses the indexed engine.
Cause: Too many tables or columns indexed, or lookup columns that are pulling in distantly related records.
Fix: Audit your table-level search configuration and remove any tables that users realistically never search for. If lookup column indexing is the issue (e.g., an Account lookup on a low-value configuration table is polluting results), remove that lookup column from the Quick Find find columns.
Cause: An older app that was built before Dataverse Search was enabled may have cached settings, or there's an app-level setting overriding the environment default.
Fix: Check the model-driven app's settings. In the app designer, look for search-related app properties. Some organizations pin their apps to specific search behaviors. Republish the app after making environment-level changes.
Cause: Dataverse Search doesn't index numeric column types.
Fix: Consider creating a formula column that converts the number to text using Text() — this text column can then be added to the search index. Name it something like Project Code (Searchable) and hide it from forms. This is a legitimate pattern for asset IDs, serial numbers, and order numbers that are stored as numbers for sort/calculation purposes but need to be text-searchable.
Warning
Formula column search indexing has its own nuances — formula columns are calculated at query time, not stored, so verify that your specific formula column type is eligible for indexing before building your data model around this pattern. As of recent releases, simple text formula columns are indexable, but complex or cross-table formulas may not be.
Cause: Index update batch jobs for large imports can take hours.
Fix: This is expected behavior. Communicate the delay to users. For time-sensitive scenarios, use the per-table view (which queries live data) to verify import results immediately, and use global search after index propagation is complete.
This should not happen. Dataverse Search applies security row-level filters at query time — users only see search results for records their security role grants access to. If you're observing unexpected record visibility, the issue is in your security role configuration, not in search. Review your security role and table permission setup and verify that read access is configured as intended.
It's worth emphasizing a non-obvious dependency: the views you configure for your tables — particularly Quick Find views, but also the default views — determine what users see after a search, not just what they can search for. Configuring Model-Driven App Views as Default Views, Quick Find Views, and Lookup Views goes deep on this relationship. The short version: a well-configured Quick Find view makes search feel fast and contextual; a poorly configured one makes even good Dataverse Search results feel useless because the result list shows unhelpful columns.
Similarly, when Dataverse Search returns global results and a user clicks into a specific table's results, they're taken to that table's default active view. If that view has a confusing column set or poor default sort, users will have a bad experience even though the search itself worked correctly. Search configuration and view configuration are partners.
Search is a core usability feature in any model-driven app with significant data volumes, and Dataverse Search is meaningfully better than Quick Find for global, cross-table discovery. But "enabling" it is only the beginning. The real work is:
The patterns here extend naturally into more advanced territory. Once search is configured well, users will naturally want smarter filtering within search results — which leads into configuring views as filters and building dashboard-level analytics on top of search patterns. For the dashboard side of that story, Configuring Model-Driven App Charts and Dashboards: Visualizing Dataverse Data with Built-In Analytics is the next logical stop.
If your organization is maturing toward compliance and audit requirements, note that Dataverse Search configuration changes are themselves auditable — enabling or disabling a table for search is a customization event. The full story on tracking configuration and data changes lives in Configuring Dataverse Auditing and Field-Level Change History in Model-Driven Apps.
Search well-configured is invisible in the best possible way. Users find what they need, trust the app, and stop workarounding it. That's the goal.
Model-Driven Apps & Dataverse