7.2 Custom Knowledge Sources for Advanced Responses
Key Takeaways
- Knowledge sources ground generative answers with enterprise or public data and can be attached at agent level (Knowledge page) or scoped on a generative answers node in a topic.
- Supported sources include public websites, uploaded documents (Dataverse storage), SharePoint, Dataverse tables, and enterprise data via Microsoft Copilot connectors—with different limits in classic vs generative orchestration.
- SharePoint, Dataverse, and connector knowledge use the agent user's Microsoft Entra ID permissions so answers only surface content that user can access.
- Structured sources (Dataverse tables) suit factual row retrieval; unstructured files and SharePoint content suit narrative policy and FAQ grounding—source quality and indexing limits drive answer quality.
- Agent settings such as Allow ungrounded responses, Web Search, content moderation, and tenant graph grounding with semantic search materially change whether answers stay grounded and how search quality behaves.
7.2 Custom Knowledge Sources for Advanced Responses
Quick Answer: Add knowledge sources at agent level or on a generative answers node so the agent retrieves approved content, then generates grounded replies with citations. Choose websites, file uploads, SharePoint, Dataverse, or connector-indexed enterprise data; respect auth (Entra ID for internal sources), orchestration limits, and Generative AI settings that block or allow ungrounded answers.
AB-620 skill Configure advanced agent responses with custom knowledge sources is about grounding—giving the large language model trusted material before it speaks—not about replacing every topic with a single search box. You will be tested on source types, where knowledge is attached, how orchestration modes change limits, and which settings protect answer quality.
Why knowledge exists beside topics and prompts
Authored topics handle known intents with fixed flows. Custom prompts transform text with explicit instructions. Knowledge + generative answers fill the long tail: policy questions, product FAQ, handbook lookup, and table-backed facts the maker never scripted turn-by-turn.
Published agents that contain knowledge use configured sources to ground the published agent. You can add knowledge:
- During agent creation
- After creation on the Knowledge page (agent-wide)
- On a generative answers node inside a specific topic (intent-scoped grounding)
By default, new agents get a Conversational boosting system topic with a generative answers node. Agent-level knowledge is wired into that boosting path so unmatched utterances still try grounded answers.
Supported knowledge sources (exam table)
Microsoft’s knowledge summary maps sources like this (limits differ by classic vs generative mode):
| Name | Source style | What it searches | Auth |
|---|---|---|---|
| Public website | External | Bing-restricted to provided site URLs | None |
| Documents (file upload) | Internal | Documents stored in Dataverse | None |
| SharePoint | Internal | SharePoint URL via GraphSearch | Agent user’s Microsoft Entra ID |
| Dataverse | Internal | Environment tables via RAG-style retrieval | Agent user’s Microsoft Entra ID |
| Enterprise data (connectors) | Internal | Org data indexed by Microsoft Search | Agent user’s Microsoft Entra ID |
Classic mode example caps (Conversational boosting / generative answers node): about 4 public website URLs, 4 SharePoint URLs per node, 2 Dataverse knowledge sources with up to 15 tables each, uploaded files limited by Dataverse storage, plus classic-only sources such as custom data in some node configurations.
Generative orchestration raises many caps (for example more websites/SharePoint URLs) and can filter beyond 25 knowledge sources with an internal GPT selection step—so descriptions on knowledge sources matter. Uploaded files are not counted in that 25-source filter in the same way. Generative orchestration does not support some classic-only sources (custom data, Bing Custom Search) as agent-level knowledge; embed those in a generative answers node when required.
Structured vs unstructured grounding
Think in two buckets when designing for AB-620 scenarios:
| Kind | Examples | Strengths | Failure modes |
|---|---|---|---|
| Unstructured | PDF/DOCX uploads, SharePoint pages, public site articles | Narrative policy, how-to, FAQ language | Stale files, huge scans, weak headings, OCR-poor PDFs |
| Structured | Dataverse tables, connector enterprise indexes | Precise entities, filters, row-level security via user identity | Wrong tables selected, missing columns, poor synonyms |
File uploads index document contents into Dataverse storage—good for controlled handbooks you own end-to-end. SharePoint reuses existing intranet libraries but requires user auth and correct site/library URLs; GraphSearch returns what the signed-in user may see. Dataverse knowledge applies retrieval-augmented generation over selected tables—ideal for product SKUs, entitlement matrices, or FAQ entities modeled as rows. Websites must be organization-owned properties you intend Bing to search through Copilot Studio.
Unstructured connector and OneDrive/SharePoint file scenarios have additional limits documented under unstructured data knowledge—do not assume unlimited size or every file type behaves identically. Citations from knowledge generally cannot be piped as direct inputs into other tools; plan separate API/tool calls if you need machine-readable IDs.
Authentication and audience design
For SharePoint, Dataverse, and connector enterprise data, agent user authentication is not optional decoration: when User A asks, the agent only surfaces content User A can access. That is a security feature and a UX design constraint—external anonymous agents cannot pretend to be Entra-backed SharePoint readers.
Configure end-user authentication on the agent (Authenticate with Microsoft is required for features such as tenant graph grounding with semantic search). Topic-level generative answers nodes also surface authentication considerations when knowledge needs a signed-in user.
Generative AI and Overview settings that change answers
These agent settings are frequent “why did grounding fail?” exam targets:
| Setting | Effect |
|---|---|
| Allow ungrounded responses | When off (with generative orchestration), blocks turns where the agent answered from general knowledge/history without calling knowledge or a tool; fallback topic can fire. When on, model general knowledge may answer without a source call. |
| Use information from the web / Web Search | Parallel Bing web grounding interleaved with configured public site sources (generative orchestration). |
| Content moderation | Agent-level default; topic generative answers node can override; prompt tools have their own level for managed models. |
| Tenant graph grounding with semantic search | Improves SharePoint/connector retrieval quality via semantic index; needs Authenticate with Microsoft; may add cost/latency; larger file support when licensed correctly. |
| Official sources (classic-oriented) | Mark highly trusted sources; not compatible with generative orchestration the same way—know the mode interaction. |
When Allow ungrounded responses is off, answers typically must include in-text citations to the knowledge hit. Models sometimes produce correct text without citation markers; the platform may withhold that answer as if nothing was found. Mitigations: instruct the agent to always cite sources; avoid instructions that strip references or force formats that kill citation markers; for custom data sources include ContentLocation and Title so citations can form.
Channel quirks: Microsoft Teams may cap citation count and truncate titles/snippets. If you customize the generative answer rendering (clear the Message and rebuild via variable or Adaptive Card), you own citation UI—automatic citation rendering may not apply.
Agent-level vs topic-scoped knowledge (design pattern)
Agent-level knowledge is the default safety net and general Q&A brain. Topic-scoped generative answers shine for intent-based grounding: a Refunds topic points only at Billing and Legal SharePoint folders so a returns question never digs through HR handbooks. Exam vignettes that mention “too much irrelevant knowledge” or “mixed policy domains” usually want narrower generative answers node sources, not more files dumped on the agent.
Classic data options on a generative answers node still matter for Bing Custom Search, Azure OpenAI, or Custom Data when generative-mode agent knowledge cannot carry them.
Scenario: regional HR policy agent
A multinational HR agent must answer leave-policy questions. Contoso uploads a global PDF (documents knowledge), adds per-country SharePoint site collections, and enables Entra authentication. Generative orchestration is on; makers write clear knowledge descriptions (“UK leave policy SharePoint”) so the filter picks the right source among many. Allow ungrounded responses is off so the agent cannot invent statutory leave days. A dedicated “Parental leave” topic embeds a generative answers node limited to the parental-leave library for higher precision. Analytics later show which knowledge sources produce answers—feeding content owners when a source is stale.
Grounding quality checklist
- Prefer authoritative, current documents; retire superseded PDFs.
- Split giant mixed libraries into purposeful knowledge sources with clear names/descriptions.
- Match structure: tables for SKUs and entitlements; documents for prose policy.
- Verify user auth path in the real channel (Teams vs web) before go-live.
- Test with users who have different permissions to prove security trimming.
- Align orchestration mode with source types you need (classic custom data vs generative filters).
- Tune ungrounded-response and moderation settings deliberately—not as afterthoughts.
Knowledge vs prompt vs HTTP (selection table)
| User need | Mechanism |
|---|---|
| “What does policy say about X?” | Knowledge + generative answers |
| “Rewrite this answer in plain language” | Custom prompt on text you already have |
| “What is my open order status right now?” | HTTP / connector / tool against live API |
Do not force live transactional state into monthly PDF uploads. Do not call HTTP for static handbook prose you already own as knowledge.
Custom knowledge sources turn advanced responses into auditable, permission-aware grounding—core Domain 1 configuration for AB-620.
Which statement correctly describes authentication for SharePoint knowledge in Copilot Studio?
A maker turns off Allow ungrounded responses with generative orchestration enabled. What is the intended effect?
Why might a maker place knowledge on a generative answers node inside a specific topic instead of only at agent level?