Knowledge search for agents

What it does

Knowledge search is the control an agent uses to find articles from inside a case, a conversation or the standalone Knowledge Search page. It runs on Dataverse search, supports a small set of operators, and its behaviour is tuned from the Knowledge page in the Copilot Service admin center rather than from the form designer.

Key facts

Dataverse search is on by default in production environments, except those using customer-managed encryption keys. Without it, knowledge search falls back to SQL full-text search and behaves noticeably worse.
Default search mode is any — an article matches if it contains any of the entered keywords. Switching Set search mode as all to Yes in Knowledge > General settings > Knowledge search experience requires every keyword to match.
Supported operators: + for AND, | for OR, - for NOT, * as a trailing wildcard, and double quotes for an exact phrase. Common words (a, an, the) are dropped from quoted phrases.
Which fields are searched is governed by the Quick Find view columns on KnowledgeArticle, plus Dataverse search's searchable-field configuration. Results can match on keywords, description, article number and attachment content.
Case and Conversation are enabled for knowledge search by default. Other tables are added under Knowledge > Record types > Manage.
Enable suggest as you type shows a flyout of matching article titles as the agent types. It matches on title only, not body.
Show recently viewed knowledge articles can display between 1 and 8 recent articles.
Search filters can be built on Option set, Multiselect option set, Lookup, Two options, and Date and time fields. Custom fields must be added to the Quick Find view columns first.
Filters are enabled by default. Out-of-the-box filters cannot be deleted. Turn on Allow customer service representative to personalize and an agent's own filter defaults persist — an administrator changing the default later will not overwrite them.
Field-level security is respected: a filter on a secured field simply does not appear for agents who lack access.
The number of results returned is set per control in Knowledge > General settings, but that value is ignored the moment any external search provider is configured.

When to use / skip

Every Customer Service implementation with knowledge turned on uses this. The decision is not whether, but how much configuration you do beyond the defaults.

The defaults are fine for a single-product, single-language desk with a few hundred articles. Agents type a phrase, get a list, open one. Nothing to tune.

You start needing to work at it when the article count goes past a couple of thousand, or when there are distinct product lines whose vocabulary overlaps. That's when searchMode=all, search filters and disciplined keyword hygiene stop being nice-to-haves. Be honest with the client about the order of operations though: search configuration cannot rescue a KB of badly written articles with no keywords. If the content is poor, spend the budget on content.

Skip suggest-as-you-type if the article titles are long or bureaucratic. It matches titles only, so a KB full of "PROC-114 — Refund handling (EMEA)" style titles produces a flyout that helps nobody.

Configuration decisions

any versus all search mode. all gives sharper results on a large KB but frustrates agents who type a full sentence from the customer. Decide with a real corpus, not in a workshop.
Which tables beyond Case and Conversation get the knowledge search control, and whether it appears in the app side pane, on the form, or both.
Which fields become search filters, and which of those are preselected. Preselected filters are powerful and quietly dangerous — see gotchas.
Whether agents can personalise filters, accepting that you lose the ability to change their defaults afterwards.
Whether custom fields need adding to the Quick Find view columns, which affects Dataverse search indexing across the whole environment, not just this control.
How many results to show per search — and whether that setting matters at all, given external search providers override it.

Gotchas

Turning on searchMode=all after go-live changes results overnight and agents will report it as a bug. Communicate it, or better, pilot it with one team first.
A preselected filter silently narrows every search. Agents assume they are searching the whole KB. Set a preselect on Product, and articles with no product set become invisible.
Agent-personalised filter defaults survive administrator changes. Once you've enabled personalisation you cannot cleanly push a new default to everyone.
Adding fields to the Quick Find view to make them filterable also changes what Dataverse search indexes and what quick find returns elsewhere in the app. It is not a knowledge-only change.
Wildcards only work as a trailing *. Agents who type *fund expecting to find "refund" get nothing, and conclude search is broken.
If Dataverse search is disabled — which happens in environments with customer-managed keys — the search experience degrades quietly rather than erroring. Check this on any environment you did not provision yourself.
Attachment content is searchable, which is useful right up until someone attaches a document containing information they did not intend to publish.

Consultant notes

Demo search with the client's own migrated content, not sample data. Search quality is entirely a function of the corpus and demos on sample data mislead everyone.
Get a keyword convention agreed in the first content workshop. Keywords carry a lot of the ranking weight and are the cheapest lever the client controls.
Before go-live, sit with two agents and watch them search for five real cases. You will find more in twenty minutes than in any amount of configuration review.
Push back on requests to make search "work like Google". You can tune fields, filters and mode; you cannot tune relevance ranking directly.
Check the Dataverse search status in every environment on the project, including sandboxes used for UAT. Different behaviour between UAT and production is almost always this.

Worth revisiting once the KB passes a few thousand articles, or if Microsoft changes the Dataverse search relevance model.