How It Works

You do not need any of this to use Universal Search. See Getting Started for that. This page is for anyone who wants to understand what happens under the hood, at a level that does not require reading AL.

Search reads an index, not your live tables

A search does not scan your business tables while you wait. A dedicated index table holds a searchable copy of every field you configured, built ahead of time and kept current in the background. For each indexed field, the index stores a few normalized forms of the same text side by side: a cleaned up version for exact and prefix matching, a version with spacing stripped out so word boundaries do not matter, and a phonetic key for fields with sounds alike matching turned on. Business Central's own full text search indexing accelerates the exact and prefix lookups against that table, so the fast path stays fast as the index grows.

The index stays current without anyone re-scanning anything

The index updates through Business Central's own system level change events, the same mechanism the platform uses for its change log, rather than by periodically re-scanning your tables. The moment a record in a configured table is created, changed, deleted, or renamed, that change is queued.

A background job, running on Business Central's standard job queue, drains that queue continuously and applies each change, normally within a minute, with no manual step. A full rebuild, triggered from Index Configuration or automatically the first time a table is configured, walks the source table once to seed the index from scratch. After that, it is live updates only.

A search tries the cheap match first, then gets more forgiving

A single search runs through several passes, from strictest to most forgiving:

1. An exact and prefix pass against the normalized text, using Business Central's full text index. This alone covers most everyday searches instantly.
2. A spacing insensitive pass, so word boundaries in the query do not have to match word boundaries in the data.
3. A sounds alike pass, for fields with phonetic matching turned on.
4. Progressively more forgiving passes, mid word fragments, partial coverage across multiple words, and typo tolerance, that only run when the earlier, cheaper passes have not already found enough results.

That ordering matters for speed as much as relevance. The fuzzier a pass gets, the more it costs to run, so Universal Search only reaches for it when it is actually needed.

Results are ranked, not returned in table order

Every candidate match is scored and ranked before it reaches you. Nothing comes back in arbitrary table or insertion order. At a conceptual level, the score combines:

• Match quality: an exact match is stronger evidence than a mid word fragment, which is stronger than a sounds alike match, which is stronger than a typo tolerant one.
• Field weight: the weight you set per field in Index Configuration, so a hit on a field you told Universal Search matters more, like a No. or Name field, outranks the same strength of match on a lower weighted, more descriptive field.
• Tightness of fit: how much of the matched field your query actually accounts for, so a short, precise query matching a short field ranks a touch higher than the same query buried in a much longer one.

The result is a single, best first ranked list across however many tables you configured, grouped and capped per table in the mixed view (see Getting Started) so no one table buries the rest.

Nothing is shown without a live permission check

Ranking and retrieval happen against the index, but nothing is ever handed back to a user without a live permission check against the real record. A result the searching user cannot actually open is dropped before it is shown, and a stale index entry for a record or table that no longer exists is handled the same way.

Note: Universal Search's index accelerates search. It is never a second, less guarded copy of your data.