Configuring Dataverse Search

In any modern business application, the ability to find information quickly is the difference between a productive user and a frustrated one. Imagine a sales representative standing in a busy lobby, trying to find a specific contact's phone number or the details of a recent meeting note. They don't have time to navigate through three levels of menus or remember exactly which table a specific piece of information lives in. They need a search bar that works like the ones they use on the web—one that understands typos, searches across multiple types of records simultaneously, and returns the most relevant results first.

This is where Dataverse Search comes in. Formerly known as Relevance Search, Dataverse Search is a high-performance, intelligent search service powered by Azure Cognitive Search. It sits on top of your Dataverse data and provides a global search experience across your entire environment. Unlike traditional database queries that look for exact matches in specific columns, Dataverse Search uses specialized indexing to provide fast, flexible, and context-aware results.

In this lesson, we will dive deep into how to configure, manage, and optimize Dataverse Search. We will look at how the indexing process works, how to choose which data is searchable, and how to refine the user experience so that your team can find exactly what they need in seconds.

Understanding the Dataverse Search Architecture

Before we start clicking buttons in the admin portal, it is important to understand what is happening behind the scenes. Dataverse Search does not run directly against your SQL database. If it did, complex searches across dozens of tables would slow down the entire system for everyone.

Instead, Dataverse Search uses an external search index. When you enable a table for search, Dataverse begins syncing that data to an Azure Cognitive Search index. This index is optimized specifically for searching text. It breaks down words into their root forms (a process called "stemming"), handles common misspellings (fuzzy matching), and can rank results based on how often a term appears in a record.

When a user types a query into the search bar at the top of a Model-driven app, the request goes to this external index. The index returns the IDs of the matching records, and Dataverse then displays those records to the user, respecting all the security permissions already in place. This separation of the search engine from the primary database ensures that searching stays fast even as your data grows into the millions of rows.

Callout: Dataverse Search vs. Quick Find

It is easy to confuse Dataverse Search with "Quick Find." Quick Find is the search box found on a specific grid or view (like a list of Active Accounts). Quick Find is "table-specific," meaning it only looks at the records in that specific view. Dataverse Search is "global," meaning it searches across Accounts, Contacts, Leads, Opportunities, and any other enabled tables all at once. Furthermore, Quick Find uses standard SQL 'LIKE' queries, while Dataverse Search uses full-text indexing, making it significantly faster and smarter for large datasets.

Enabling Dataverse Search at the Environment Level

The first step in using Dataverse Search is enabling it for your specific Power Platform environment. By default, new environments may have this enabled, but for older environments or specific configurations, you might need to turn it on manually.

Step-by-Step: Enabling the Feature

1. Navigate to the Power Platform Admin Center (admin.powerplatform.microsoft.com).
2. Select Environments from the left-hand navigation and click on the name of the environment you want to configure.
3. Click on Settings in the top toolbar.
4. Expand the Product section and select Features.
5. Locate the Search section. You will see a toggle for Dataverse Search.
6. Switch the toggle to On.
7. Scroll to the bottom of the page and click Save.

Once you enable this setting, the system begins the initial synchronization process. Depending on the volume of data in your environment, it can take anywhere from an hour to a full day for the initial index to be built. During this time, users might see incomplete results or a message indicating that the search is still being set up.

Note: Enabling Dataverse Search does not consume additional database storage in the same way that adding rows does, but it does require your environment to have a minimum amount of available storage capacity. If your environment is over its storage limit, you may be unable to enable or update search settings.

Selecting Tables for the Search Index

After the environment is ready, you must decide which tables (entities) should be included in the global search. You shouldn't include every single table in your system. Including "junk" tables or background system logs will clutter the search results and make the index less efficient.

How to Add Tables to Search

To manage which tables are indexed, you use the Power Apps Maker Portal (make.powerapps.com).

1. Open your Solution (it is best practice to do this within a custom solution rather than the Default Solution).
2. In the solution explorer, look at the top bar for an option labeled Overview.
3. In the "Dataverse Search" card, you will see a list of how many tables are currently indexed. Click Manage search index.
4. A panel will appear on the right side of the screen listing all available tables.
5. Check the boxes for the tables you want to include (e.g., Account, Contact, Opportunity, Custom Project Table).
6. Click Save.

When you add a table here, you are telling the system to start syncing the data from that table to the Azure index. However, simply adding the table isn't enough. You also need to tell Dataverse which columns within that table should be searchable.

Configuring Search Columns and Views

Dataverse Search relies on a specific view within each table called the Quick Find View. Even though we are using Dataverse Search (the global tool), the configuration for what is "searchable" is still managed within the Quick Find View settings of each individual table.

There are three types of columns you need to configure in the Quick Find View:

1. Find Columns: These are the columns that the search engine actually looks at. If you type "Seattle" and the "City" column is not a Find Column, the record won't show up.
2. View Columns: These are the columns that appear in the search results UI. These provide context to the user so they can distinguish between two records with the same name.
3. Filter Columns: These are used to create the facets (filters) on the left side of the search results page, allowing users to narrow down results by "Owner," "Created On," or "Status."

Step-by-Step: Configuring Columns

1. In the Maker Portal, navigate to the Table you want to configure (e.g., Contact).
2. Select the Views tab.
3. Find the view with the type Quick Find View (usually named "Quick Find Active Contacts"). Open it.
4. On the right-hand side, click Edit find table columns.
5. Add the columns you want the engine to search through (e.g., First Name, Last Name, Email, Business Phone, Job Title).
6. Click Apply.
7. Now, look at the columns displayed in the view layout itself. These are your View Columns. Add columns like "Company Name" or "Email" to the view so users can see this info in the search results.
8. Click Save and Publish.

Tip: Be selective with your Find Columns. If you add a column that contains massive amounts of text (like a "Description" or "Notes" field) to the Find Columns, it can sometimes lead to "false positives" where a record appears in search results because of a random word in a long note, even if it's not actually relevant to the user's query.

The Search API: For Developers

While most users interact with Dataverse Search through the UI of a Model-driven app, developers often need to access these powerful search capabilities programmatically. This is particularly useful when building custom Power Pages, Canvas Apps, or external integrations where you need a "Google-like" search experience over Dataverse data.

The Dataverse Search API is a Web API endpoint that allows you to send a query and receive a JSON response of ranked results.

Example: Search API Request

Here is a conceptual example of what a search request looks like using the search function in the Dataverse Web API.

POST [Organization URI]/api/data/v9.2/search
Content-Type: application/json
Accept: application/json

{
    "search": "Contoso",
    "usefuzzy": true,
    "entities": ["account", "contact"],
    "top": 5,
    "orderby": ["name asc"]
}

Explanation of the Request:

• search: The actual string the user typed.
• usefuzzy: When set to true, the engine will find results even if there are slight typos (e.g., "Contoso" will find "Contosso").
• entities: This allows you to scope the search to specific tables for this specific request, even if more tables are indexed globally.
• top: Limits the number of results returned (useful for pagination).
• orderby: Determines the sort order of the returned JSON.

The response will include not just the record IDs, but also "highlights"—snippets of text showing exactly where the search term was found within the record, with the matching words wrapped in <b> tags. This is exactly how the Model-driven app displays search snippets.

Advanced Search Features

Dataverse Search isn't just about finding words; it includes several intelligent features that improve the user experience significantly.

Natural Language Search

Dataverse Search can interpret certain types of natural language queries. For example, if a user types "contacts in Seattle," the engine understands that "contacts" refers to the table and "Seattle" is a value in the address column. It can also handle date-based queries like "accounts created last week." This reduces the need for users to build complex filters manually.

Intelligent Suggestions

As a user starts typing in the search bar, Dataverse Search can provide "suggested results" before the user even hits the Enter key. This is based on the primary field of the indexed tables. This provides an immediate "jump-to" capability that saves time.

Synonyms

While not always configured by default, the underlying Azure Cognitive Search engine supports synonym maps. This allows you to define that a search for "Cell" should also return records containing "Mobile" or "Phone." This is particularly useful in industries with heavy jargon or multiple terms for the same concept.

Faceted Navigation

When the search results page opens, users will see a list of filters on the left. These are called facets. They allow users to see a count of how many results fall into specific categories (e.g., "Industry: Manufacturing (5)"). These facets are automatically generated based on the columns included in the Quick Find View, specifically Choice columns, Boolean columns, and Lookup columns.

Callout: Security and Dataverse Search

A common concern is whether search bypasses security. The answer is a firm No. Dataverse Search is fully security-aware. The indexing process includes the security metadata for every record. When a user performs a search, the engine filters the results in real-time to ensure that the user only sees records they have "Read" access to. If a user doesn't have permission to see "Opportunities," they will never see an Opportunity in their search results, even if they search for the exact name of one.

Best Practices for Configuring Search

To provide the best experience for your users, follow these industry-standard best practices:

1. Limit the Number of Indexed Tables

While you can index hundreds of tables, you shouldn't. Focus on the core entities that users actually need to find. Every table you add increases the "noise" in the search results. If a table is only used for background calculations or internal system logic, keep it out of the search index.

2. Prioritize "Find Columns"

Only include columns in the "Find" section of the Quick Find View if they contain data users are likely to search for. Including too many columns—especially those with similar data—can dilute the relevancy of the results. For example, you likely don't need to search through "Created By" or "Modified On" fields in a global search.

3. Use View Columns for Context

When a search returns five people named "John Smith," the user needs to know which one is which. Ensure your View Columns in the Quick Find View include differentiating information, such as "Email," "City," or "Company Name."

4. Monitor Storage and Indexing Status

Keep an eye on your Dataverse storage capacity. Since search data is stored in a separate index, it contributes to your "File" or "Index" storage category. If you are nearing your limits, review your search configuration and remove unnecessary tables or columns.

5. Educate Users on Search Syntax

Dataverse Search supports special characters like + for mandatory words, | for OR logic, and "" for exact phrase matching. Providing a small "cheat sheet" to your power users can help them get much more out of the search tool.

Common Pitfalls and How to Avoid Them

Even with a straightforward setup, there are a few areas where administrators often run into trouble.

The "Missing Record" Mystery

The most common complaint is: "I just created this record, but I can't find it in search!"

• The Cause: Remember that Dataverse Search is asynchronous. It takes time for the data to sync from the database to the search index. Usually, this happens within seconds or minutes, but during high-load periods, it can take longer.
• The Fix: Check the "Search Index" status in the Power Platform Admin Center. Also, ensure the record actually meets the criteria of the Quick Find View (e.g., if the view is filtered to "Active Contacts" and you created an "Inactive" one, it won't show up).

Too Many Results (Low Relevancy)

Users complain that they search for a specific company name and get 500 unrelated results.

• The Cause: This usually happens when a very common word is included in a "Find Column" that is used across many records. It can also happen if "Fuzzy Matching" is being too aggressive.
• The Fix: Audit your Find Columns. Remove any columns that contain generic or repetitive data. Ensure that the most unique identifiers (like Account Number or Email) are at the top of the list.

Forgetting to Publish

In the Maker Portal, changes to the Quick Find View do not take effect until you click Publish.

• The Cause: An admin adds "Mobile Phone" to the Find Columns but forgets to publish the table.
• The Fix: Always use the "Publish all customizations" button or ensure the specific table is published after modifying its views.

Security Role Issues

Sometimes a user can see a record in a list view but not in search.

• The Cause: While rare, this can happen if the search index hasn't updated the security metadata for that specific user's business unit or role changes.
• The Fix: Usually, this resolves itself with the next sync. If it persists, try toggling the table off and back on in the "Manage Search Index" settings to force a re-index of that table.

Step-by-Step: Testing Your Configuration

Once you have configured your tables and columns, you should perform a "Search Audit" to ensure everything is working as expected.

1. Test for Typos: Search for a known Account but intentionally misspell it (e.g., "Contoso" as "Contoso"). If the record appears, fuzzy matching is working.
2. Test for Cross-Table Results: Search for a term that appears in both a Contact and an Opportunity. Ensure that the results page shows both types of records and that they are grouped correctly.
3. Test Facets: On the results page, look at the left-hand sidebar. Are the filters (facets) relevant? If you see a filter for a column that isn't useful, go back to the Quick Find View and remove that column from the view.
4. Test Security: Log in as a user with limited permissions. Perform a search for a record you know they shouldn't see. Confirm that it does not appear in their results.

Warning: Be careful when using the "All Columns" search option in certain legacy configurations. It is always better to explicitly define your Find Columns. Relying on the system to "search everything" is a recipe for poor performance and irrelevant results.

Quick Reference: Search Configuration Checklist

Before moving this configuration to a production environment, run through this checklist:

• Dataverse Search is enabled in Environment Features.
• Only essential tables are added to the Search Index.
• Quick Find View for each table has the correct "Find Columns" (the "what" to search).
• Quick Find View for each table has the correct "View Columns" (the "what" to see).
• Unnecessary columns are removed from the Quick Find View to keep facets clean.
• The solution has been published.
• Relevancy has been tested with common user queries.

Summary and Key Takeaways

Configuring Dataverse Search is one of the most impactful things an administrator can do to improve the user experience. By moving away from basic database queries and toward a modern, indexed search engine, you provide users with a tool that is fast, smart, and reliable.

The power of Dataverse Search lies in its flexibility. You can control exactly what is searched, how it is displayed, and who can see it. However, with that power comes the responsibility to keep the index clean and optimized. A cluttered index is just as bad as no index at all.

Key Takeaways:

• Dataverse Search is powered by Azure Cognitive Search, which runs outside the main database to ensure high performance without slowing down standard operations.
• The Quick Find View is the "brain" of search configuration. Even though the search is global, the specific columns searched and displayed are defined at the table level within this specific view.
• Fuzzy matching and natural language support make the search experience much more forgiving for end-users, allowing for typos and conversational queries.
• Security is never compromised. Dataverse Search respects all row-level security and sharing rules, ensuring users only see what they are authorized to see.
• Be intentional with indexing. Only index tables and columns that provide real value to the search experience to avoid "noise" and maintain high relevancy.
• The Search API allows for custom development, enabling the same powerful search features to be used in custom apps, websites, and integrations.
• Regularly audit your search results. As your data grows and changes, your search configuration should evolve to ensure the most important information always rises to the top.