TL;DR
Three layers in order: exact identifier, then attributes, then global fuzzy search. Microsoft documents all three, and the third runs on the hardest lines.
In three layers, tried in order: an exact identifier match, then a semantic match on attributes, then a broad fuzzy search across everything. Each layer runs only when the one above it found nothing.
That ordering is the whole design, and understanding it tells you exactly which of your quote lines will be right and which will need a person.
For the engineer scoping an RFQ system, and the sales lead who has to trust its output. 7 minute read.
What are the three layers?
Microsoft documents them for Business Central's Sales Order Agent [GA], and the wording is worth reading closely:
1. "Exact identifier match by item number, vendor item number, GTIN, or cross-references. Exact identifier matches have the highest confidence." 2. "Semantic attribute matching uses item attributes from the customer's message (such as color, material, or size) and AI to rank candidates by relevance." 3. "Broader fuzzy search falls back to a global search across all items when the direct and attribute-based searches don't produce results."
Layer one is not AI. It is a lookup. If the customer wrote your item number, or a code you already hold against them, the answer is deterministic and Microsoft says so — "the highest confidence."
Layer two is where judgement enters. Colour, material, size, ranked by relevance. A model is deciding which candidate best fits words the customer chose.
Layer three is a search of last resort, and §3 is about why that matters more than it sounds.
Which tables does it search?
Eight, and the list tells you what to fix in your own data:
| Table | What it contributes |
|---|---|
| Items | Number, description, search description, GTIN, vendor item number |
| Item Reference | The codes your customers use for your products |
| Item Variant | Code and descriptions |
| Item Attributes | Name and value |
| Item Category | Code, description, parent |
| Item Translation | Language-specific descriptions |
| Item Identifier | Code |
| Extended text Line | Free text held against the item |
Item Reference is the one that compounds. It is a standard Business Central table holding this customer calls that item this. Every entry turns a layer-two judgement into a layer-one lookup — permanently, for that customer. Most distributors have it nearly empty, not because Business Central lacks the capability but because somebody would have to type entries forever.
Why does the third layer worry engineers?
Look at what it is asked to do. It runs only when the first two found nothing — the hardest lines, the weakest signal — and its job description is to produce a candidate anyway.
A global search across every item will almost always return something.
Microsoft publishes two failure modes that live exactly here. A partial-word problem: "When a search term appears as part of a longer word, the system fails to match it." And a substitution: "Searches for related consumables often return the main product instead of the requested accessory or consumable" — its own example asks for washing powder, and returns a washing machine.
So the design question is not whether to have a fallback. Without one, most of a real inbox comes back unmatched. The question is what the fallback is allowed to do with a weak result: put it on the quote, or put it in front of a person. Chapter 3 is entirely about that decision.
What happens when the match is ambiguous?
Layer two produces a ranking, not an answer. Sometimes the top two candidates are genuinely close — two shirts that differ only in material, two fittings that differ only in bore.
Microsoft's agent handles that by asking: "If important details are missing or more choices are available, the agent engages in multiturn email conversations to clarify the request."
That is the right instinct, and Microsoft also publishes where it strains. From its reliability notes:
"Reliability decreases if you significantly change the email the agent drafts about item availability before sending it to the customer. This issue is more apparent when the external customer follows up with an email using pronouns like "them" or "it" and other words instead of repeating specific quantities and names. For example, the customer replies, "I want them all.""
"I want them all" contains no product and no quantity. It is resolvable only against what was said in the previous message — which is why the unit of work has to be the whole thread, not the newest message in it.
A second constraint shapes how you design that loop. Microsoft documents an attribute gap: "The agent searches for items using item attributes, but the attributes aren't shown to the agent on the item availability page."
Its worked example has the catalogue holding a linen shirt and a cotton shirt, and the agent replying "We have X quantity of ITEM-1 Shirt and ITEM-2 Shirt" — both described identically, because the attribute that distinguishes them has dropped out. The customer then has to write back asking for the linen one.
The attribute that resolved the match has to travel with the match. If it was good enough to decide, it is good enough to display — to the reviewer and to the customer.
What does a reviewer need to see on a matched line?
This is our own position rather than a documented feature, and it follows from the layering above.
Which layer matched it. A line resolved by item number and a line resolved by fuzzy search are both "matched", and they deserve different amounts of attention. Showing the route costs nothing — the system already knows — and it is the single most useful fact on the row.
How far ahead of second place it finished. Two candidates can both look settled while one of them was a near-tie between catalogue entries differing only in supplier. In distribution that is common, because the same physical part legitimately exists several times under different codes.
The customer's own words, underneath. Not our interpretation — the raw fragment, and where in the request it appeared. A reviewer who cannot see where a line came from cannot check it in seconds, and review that takes minutes is review nobody does.
What limits matching before any model runs?
Your catalogue. Microsoft says so plainly about its own agent:
"Although the agent can find products based on vague and incomplete descriptions, the quality of product information in Business Central affects its effectiveness. You can improve the agent's ability to find products by enhancing descriptions, attributes, categories, and extended text of your inventory items."
And more bluntly: "How you name your products can affect agent output. For example, using cryptic abbreviations versus friendly names can reduce output quality."
One operational note worth knowing before you test anything: "It might take up to 15 minutes for newly entered data to become searchable as the system reindexes the tables in the background."
Before buying software to interpret your customers' language, it is worth asking how much of the difficulty is your own item descriptions. That fix needs no licence.
Want to know how many of your lines would resolve at layer one today? Book a 15-minute call — bring a real request and your item list, and we will sort them live. No deck.
Sources
- Sales Order Agent overview — Business Central
- Process sales quotes and orders with Sales Order Agent
- FAQ for Sales Order Agent — Business Central
This article is part of our work on the RFQ quoting engine.
Share this article
How an agent reads an RFQ, matches each line to your catalogue and prices it, and what has to happen to the lines it cannot resolve.
