Lately I’ve been working with Dataverse Search (aka: Global Search) tuning, and figured I’d jot down some of my learnings to maybe save someone else from banging their heads against a wall (until MS changes how things work of course).

First, and foremost you must realize that Dataverse Search is an environment wide setting. Meaning, if you have multiple teams/business units/apps they are all going to be pulling and displaying from the same pool of tables/fields. That said, Dataverse Search respects roles and permissions so if a table isn’t included in an App, or a given user does not have access to a result (either view row or column level security) they won’t see/match those results when searching.

Note: Be sure to see the “Limitations” section!

Searching Tips and Tricks

When performing a search, it’s useful to keep the following in mind:

Basic Search Tricks

• Table Name Boosting: Prepend or include the table name in your search phrase (e.g., account Fabrikam or contact Susan) to heavily weight and push that specific table’s records to the top of the results.
  • Note: Display names are indexed. Wrap in quotes for better results (ex: “Contact Email” [email protected])
• Exact Phrase Matching (""): Enclose terms in quotation marks (e.g., “Contoso Coffee”) to search for exact string matches instead of individual words scattered across fields.
• Automatic Fuzzy / Misspelling Search: Dataverse automatically handles minor typos and spelling mistakes by up to 1–2 characters (e.g., searching Coho Winry will still find Coho Winery).
• Built-in Synonyms & Nicknames: The engine resolves common name variations (e.g., searching Bob matches Robert) and abbreviations (e.g., active accts resolves to active accounts).

Operator Syntax (Simple Query Mode)

• Wildcards (*):
  • Use an asterisk at the end of a word for a trailing match (e.g., Alp* matches Alpine or Alpha).
  • Note: Trailing wildcards (term*) are natively supported out of the box. Leading wildcards (e.g., *pine) require full Lucene mode or Regex syntax.
• AND Operator (+ or AND): Force a term to be required (e.g., hotel +wifi or hotel AND wifi).
• OR Operator (| or OR): Match either term (e.g., wifi | luxury).
• NOT Operator (- or NOT): Exclude records containing a specific term (e.g., wifi -luxury).
• Group Precedence (): Combine logic for complex criteria (e.g., hotel + (wifi | luxury)).

Advanced / Lucene Syntax

• Fuzzy Matching Distance (~): Add a tilde at the end of a word to control spelling tolerance (e.g., Uniersty~ matches University).
• Proximity Search ("…"~N): Find words within $N$ words of each other (e.g., “airport hotel”~5 matches results where “airport” and “hotel” are separated by 5 or fewer words).
• Term Boosting (^N): Increase the relative weight/importance of one term over another in the same query (e.g., Rock^2 electronic gives double the rank weight to matches on “Rock”).
• Escaping Special Characters (\): Prefix reserved characters (+ - & | ! ( ) { } [ ] ^ " ~ * ? : \ /) with a backslash if searching for them literally (e.g., \+1-800 or ACME/Corp).

UI Rendering

When performing a search, you may find yourself wondering about how the grey sub-text is determined…

• Main Title: Primary Name column (bold).
• Grey Subtext: Displays only 1 secondary field.
  • If the search term matched a specific text/numeric field (e.g., an Account Number), Dataverse displays that matched field.
  • If no direct match triggered the subtext, it falls back to the first populated non-primary column (of an allowed type) in the Quick Find View (scanning left-to-right).
  • System metadata (such as Owner or Owning Business Unit) can override this display if the search term matches an indexed lookup or if non-text data types (like formatted dates) fail to render.

Limitations

Now let’s get into the “fun” things 🙄 about Dataverse Search.

• Each table permits only one System Quick Find View definition.
• Filter criteria defined by the Quick Find View is used for basic filtering:
  • Simple/Static filters like lookups, choice values, exact match (i.e. equals) work.
  • Operator/Pattern filters do not work (ex: contains, begins with, does not contain data, etc).
  • Note: Security/Permissions are one of the best ways to limit what users see.
• Even though “Sort by” is displayed in the configuration UI, that is completely ignored in favor of Azure AI Search ranking weight.
• Numeric fields, date fields, party lists, and polymorphic lookups (like RegardingObjectId) are ignored by the text search engine.
  • Note: These fields can be displayed and used for filtering - they just are not “searched”.
• Related fields added to a Quick Find View are ignored by the global search index.
• Columns in results are also not sortable manually while viewing results.
• Does not support Dataverse Hierarchy Security model (i.e. manager-to-report position. aka chain-of-command relationships).

Technical Details

Unless you’re a developer you probably won’t care about these things, but noting for reference:

• Dataverse Search was formerly Relevance Search which replaced Categorized/Quick Find Search, and to keep it even more fun, is often referred to as Global Search.
• The search engine is backed by Azure AI Search, utilizing vectorization, fuzzy matching, natural language processing, and relevancy scoring rather than SQL database queries.
• The search operates globally across model-driven apps, indexing text data, notes, and file attachments up to 2 MB.
• The search index also serves as the primary data index powering Copilot and generative AI features in Dynamics 365 (i.e. If it isn’t in the index, Copilot won’t know it).
• There is a maximum of 1,000 searchable fields per environment across all tables (50 standard fields are indexed by default and do not count against this quota).
• Structural changes to QVF columns or search settings can take 15 minutes to several hours to sync across the Azure AI index.