Knowledge search providers

What it does

Search providers let knowledge search reach content that does not live in this Dataverse environment. There are two distinct mechanisms with confusingly similar names: external search providers, which federate a query out to another source and show the results alongside native articles, and integrated search providers, which crawl a public website on a schedule and ingest its pages into Dataverse as knowledge records.

Key facts

External search providers come in three types: another Dynamics 365 organisation in the same tenant (cross-organisational), a SharePoint site in the same tenant, or a Microsoft Graph connector identified by its connection ID.
Each configured external provider returns three articles in the search results, with a Show more link per provider.
Configuring even one external search provider makes the "number of search results" setting in Knowledge > General settings irrelevant.
Custom security roles need Read, Create, Append and AppendTo on Knowledge Federated Article and Knowledge Federated Article Incident. Miss these and agents see an empty provider section with no error.
Cross-organisational search will move data across geographies if the target organisation sits in a different region. That is a data residency question, not a technical one.
In Microsoft Cloud for Sovereignty, external search providers are available only in Government Community Cloud.
Integrated search providers work differently: they read a site map, pull the pages, and store them as records in Dataverse. Content is then searchable like any other article.
Integrated providers need the Integrated Search API trigger flow enabled in the default solution, and the enabling user needs global prvReadWorkflow.
Target sites for integrated providers must be static — content rendered by client-side script will not be picked up. Site maps must carry lastmod tags and be served as application/xml or text/xml.
Integrated provider configuration includes a root URL, a site map URL, language filters, a field-mapping or JSON schema for the article shape, a refresh frequency (from 15 minutes upwards) and a lookback period.
Both are configured from Copilot Service admin center > Knowledge > Support experience, under their respective Manage links.

When to use / skip

Most projects don't need either of these, and that is worth saying out loud in the first workshop, because "we'll just federate our old KB" is a very common way to avoid a content migration decision.

External search providers earn their place in two situations. One is a genuine multi-organisation estate — a group with separate Dynamics environments per operating company, where agents legitimately need to see each other's articles. The other is a large SharePoint or Microsoft 365 document estate that will never be migrated: policy documents, engineering PDFs, product manuals. Pointing a Graph connector at that is far cheaper than moving it.

Integrated search providers are narrower still. They suit a public product documentation site or support site the client already maintains outside Dynamics, where the content genuinely lives there and duplicating it into articles would create two sources of truth. If the site is modern and JavaScript-heavy, it will not work, so check before you promise anything.

Skip both if the honest answer is that the old content should be migrated and retired. Federation as a permanent state means agents searching two systems forever.

Configuration decisions

Federate or ingest. Federated results stay live at source but cannot be filtered, rated or reported on like native articles; ingested content becomes Dataverse records you own.
Which provider type for external: cross-org, SharePoint, or a Graph connector — and for Graph, who builds and maintains the connector, because that is a Microsoft 365 admin job, not a Dynamics one.
Whether cross-organisational search crosses a data residency boundary, and whether the client's legal team has actually signed that off.
For integrated providers, the refresh frequency and lookback window — a 15-minute refresh on a large site is a lot of traffic for content that changes monthly.
The field mapping or JSON schema for ingested content, including which pages map to which language.
Which security roles get the federated article privileges, and whether that list matches the roles that actually use knowledge search.

Gotchas

Missing privileges on Knowledge Federated Article produce silence, not an error. Agents just don't see provider results, and you will spend an afternoon on it.
Adding one external provider overrides the result-count setting for everyone. If the client tuned that to 10 and you add a provider, they get 3 per provider and will notice.
Cross-organisational search is a data movement mechanism. It reads as a checkbox in the admin centre and as a transfer in a privacy assessment.
Integrated provider ingestion fails quietly on sites without lastmod in the site map, or served with the wrong content type. Test the site map with a plain fetch before configuring anything.
Ingested pages become Dataverse records and count towards storage. A large documentation site is not free.
Federated results are not rateable and do not appear in knowledge article analytics. If the client's KPIs are built on article usage, federated content is a blind spot.
Graph connectors respect Microsoft 365 permissions on the source. Agents may see fewer results than the administrator who tested it, which reads as inconsistent behaviour.

Consultant notes

Ask early whether the "other knowledge base" is being kept or retired. If it is being retired, federation is scaffolding and should be timeboxed.
Demo external search with the security roles the client will actually use, not as a system administrator. The privilege gap only shows up under a real role.
Test the target site map yourself before committing to an integrated provider. Client-side-rendered sites are common and the failure is not obvious in the admin UI.
Raise data residency for cross-organisational search in writing. It is the one item on this page that can stop a go-live.
Before go-live, check that analytics and reporting requirements do not silently assume all knowledge is native. Federated results will not be in those numbers.

Worth another look if the client adds a second Dynamics organisation, or if Microsoft expands the supported external provider types.