How ranking works

You do not need this page to use Universal Search, but it helps when you tune relevance or explain a result to a user. It describes how the index is kept current, how a search finds candidates in several passes from strictest to most forgiving, and how each candidate is scored and ranked. Everything runs inside your Business Central environment, in AL, with no external search service.

Search reads an index, not your live tables

A search never scans your business tables while you wait. Universal Search keeps its own index table with one entry per indexed record and field. Each entry stores the field text in four forms:

• the original text, for display;
• a normalized form: lowercase, accents folded, punctuation turned into single spaces;
• a compact form: the normalized text with all spaces removed;
• phonetic keys that describe how each word sounds, for fields with Enable Phonetic on.

The normalized, compact and phonetic columns use Business Central's optimized text search. Each form is stored up to 250 characters.

The index stays current in the background

While indexing is enabled, Universal Search listens for inserts, changes, renames and deletes on the tables that have rows on Search Index Configuration. Each change is written to a queue using the app's own permissions, so users who change records do not need a Universal Search permission set. The background job, Universal Search background indexing, runs every minute: it applies the queued changes, then rebuilds any table in Pending rebuild. See Start indexing.

A search runs in passes

Text shorter than two characters, after normalization, returns nothing. Otherwise the search runs these passes in order, and each record keeps only its best score:

1. Full text. Every word you typed must match the start of a word in the field, in any order.
2. Compact. Your text without spaces must match the start of the field without spaces, so icecream finds Ice Cream.
3. Phonetic. The sound of every word must match, so Carl finds Karl.
4. Contains. Your text without spaces appears anywhere inside the field, so tani finds Itani. Needs at least three characters.
5. Multi-fragment. Every word of three or more characters appears somewhere inside the field, so maro orp finds Omaroon Corporation.
6. Partial words. For searches of two or more words, records that match only some of the words, scored by how many matched.
7. Typo. The first word you typed, if it has three or more characters, is compared letter by letter with the words of fields that start with the same letter, allowing one edit in a three- or four-letter word and two in a longer one.

Passes 4 to 7 are the most expensive, so they run only while the results found so far have not filled the current page.

How a candidate is scored

Each pass gives a match a base quality:

Match	Quality
Field equals the search exactly	1000
Field starts with the search	850
Field contains every word as a whole word	700
Every word matches the start of a word	600
Partial words	up to 600, by share of words matched
Compact	500
Contains	450
Multi-fragment	420
Phonetic	350
Typo, one edit	300
Typo, two edits	200

A typo match in a search of several words is divided by the number of words. The final score is:

Score = Quality x Weight x LengthFactor / 100, plus 50 when the field starts with your first word.

• Weight is the 1 to 10 value on the field's Search Index Configuration row.
• LengthFactor is between 100 and 200 and grows as your search covers more of the field, so a short field that you matched almost completely ranks above a long field where your words are a small part.

The All view caps each table

Results are sorted by score. In the All view, each table shows at most Group Cap in All View results, 5 by default, so one large table cannot bury the others. The chip counts are taken before the cap, so they show every match found. Choosing a chip removes the cap for that table.

Permission checks

Before results are shown, Universal Search checks whether the searching user can read each table. Tables the user cannot read are dropped from both the results and the chip counts. The check is made per table, not per record, and security filters are not applied to individual results, so leave tables protected by security filters out of the index. Opening a record checks the read permission again, together with whether the record still exists.

What's next

Use this to put the right records first: Tune relevance.