Almanac
Microsoft/dataversePower Platform

Consultant KB for Microsoft Dataverse, the data layer under Dynamics 365 and the Power Platform: data model, security model, business logic, APIs and integration, search and queries, analytics and Fabric, ALM and solutions, administration, governance and compliance, and Dataverse as an agent data platform, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Dataverse release plans, docs repo and product blog, plus the author's own consultant notes.

feature-dataverse-search.mdv1 · history
CurrentApplies to MakerUpdated last monthSource Microsoft Learn

What it does

The external search index that sits alongside your Dataverse database and powers the global search bar in model-driven apps, plus the grounding data behind Copilot and agent experiences. It ranks results by relevance across multiple tables at once, tolerates misspellings, and searches inside attached documents.

Key facts

  • Configuration is driven by each table's Quick Find view. Find columns become the searchable fields, View columns become what's displayed and what can be faceted, and Filter conditions constrain results.
  • The index holds a maximum of 1,000 searchable fields per organisation. Fifty are consumed by default, leaving you roughly 950 to allocate. There's no cap on the number of tables.
  • Field types don't cost the same. A lookup counts as three fields in the index, a choice or state/status column counts as two, everything else counts as one.
  • Only single line of text, multiple lines of text, lookups and choices are searchable. Find columns of any other type are silently ignored, and related-table columns are ignored entirely.
  • A set of filter operators aren't supported at all — Like, NotLike, BeginsWith, EndsWith, Under, Above, Null, NotNull and several others. Put them in a Quick Find view and they just don't apply.
  • Configuration changes can take up to 15 minutes to show up. A full sync takes an hour or more for an average organisation and a couple of days for a large one.
  • Turning it off deprovisions and removes the index within 12 hours. Turn it back on after that and you're paying for a full sync again.
  • Indexed attributes can't exceed 1,700 bytes. Widen a text column that's in a Quick Find view and solution import can fail with a length validation error.
  • Document search covers PDF, Office formats, HTML, XML, ZIP, EML, plain text and JSON, including notes and attachments, up to 2 MB per file for global search.
  • The index counts towards your tenant's database storage entitlement. There's a per-table breakdown report in the Power Platform admin center under Capacity.

When to use / skip

Turn it on. It's opt-out for a reason, and with it off your Copilot and agent experiences are degraded for both makers and users. The real decision isn't whether to enable it, it's how much of your schema to index — every field you add costs storage and sync time, and you only get 950. Be ruthless about the Quick Find views. The other honest point: if users are doing "contains" searches on a big text column, Dataverse search is the right answer and a query with a leading wildcard is not. That's the migration conversation worth having.

Configuration decisions

  • Which of the two switches you turn on — indexing for AI and agent experiences, indexing for the global search bar, or both. They share the same index data.
  • Which tables get indexed and, more importantly, which Find columns go into each Quick Find view, given the 1,000-field ceiling and the multiplier on lookups and choices.
  • Which four View columns become the facets users see, since only the first four facetable fields in the Quick Find view are used.
  • Whether any table holds data sensitive enough to set Can enable sync to external search index to False, which has to be decided before the solution goes managed.
  • Whether to extend results into SharePoint, Bing and Office via the Microsoft Search connector.

Gotchas

  • Turning on the global search bar kills quick find (categorised) search across every model-driven app in the environment. You can't keep both, and you can't turn it off per app.
  • Common columns like ownerid, statecode and the primary name are in the index for every table by default. Add a common field to one table and global search hits it everywhere, so global results and table-level results legitimately differ. Users will report that as a bug.
  • Calculated columns and lookups don't sync on their own. The row only refreshes when a column configured for search is updated on that record.
  • The Quick Find view has to be the default view for the table, and the table has to be in the app, or results don't show up at all. Two separate things people forget.
  • Once a managed solution installs a table with Can enable sync to external search index set, that property is managed and you can't change it in the target.

Consultant notes

  • Budget the index the way you'd budget storage. Do a field count during design, not after the warning banner appears in solution explorer.
  • Warn clients that switching search on isn't instant. A large environment can take days to complete its first sync, so don't schedule the demo for the morning after.
  • If a client is on-premises customer engagement, Dataverse search isn't available at all — quick find is the only option. Worth saying early rather than in UAT.
  • Kazakh is the documented exception on language processing, handled by a language-agnostic text processor rather than the organisation base language. Rarely relevant, occasionally decisive.

Worth another look if the searchable field ceiling moves, or when the Work IQ indexing switch changes what's grounded by default.

Was this accurate?