Purview governance<\/a> can reinforce retention, sensitivity, audit, and information-protection expectations around enterprise content.<\/p>\nFor current Copilot Studio programs, the durable approach is to choose each source for authority, freshness, permissions, and retrieval quality; keep provenance visible; and remove obsolete knowledge before it becomes a confident wrong answer.<\/p>
Knowledge-source selection should also consider scale. A handful of curated documents can work well for a narrow internal agent, while a large enterprise corpus needs stronger information architecture, ownership, permission hygiene, and lifecycle. The platform can retrieve from many sources, but governance determines whether those sources remain trustworthy over time.<\/p>\n
Source descriptions matter because makers and operators need to understand why each repository is attached. Record the business purpose, owner, intended audience, freshness expectation, and sensitivity. That metadata turns \u201cSharePoint site added\u201d into an understandable design decision.<\/p>\n
Permission testing should include users with different roles. An administrator or maker can accidentally conclude that grounding works correctly because their own account can access everything. Test with representative end users to confirm that retrieval is trimmed to the right content for each role.<\/p>\n
When sources overlap, define precedence. A formal policy site may need to outrank a project wiki, even if both contain similar words. Use governance, content cleanup, metadata, and source design to reduce contradictions before asking the model to reconcile them.<\/p>\n
Documents should retain recognizable provenance after ingestion. Users and support teams should be able to trace a response back to the original source, not merely an internal document identifier. Provenance is essential when someone challenges an answer or needs the latest approved version.<\/p>\n
Freshness monitoring should identify failed refreshes or stale content. A source can remain technically connected while no longer reflecting current policy. For high-value agents, add a simple operational check such as last update time, owner review date, or source health indicator.<\/p>\n
Knowledge design should also minimize unnecessary scope. An agent built for one department rarely needs an entire tenant’s content. Smaller source boundaries can improve relevance, simplify security review, and make failures easier to diagnose.<\/p>\n
For content with very strict access or rapidly changing state, use a live tool or connector instead of copying the data into a knowledge source. Retrieval architecture should choose between indexed knowledge and live business queries based on authority, latency, freshness, and permission requirements.<\/p>\n
As the agent evolves, remove unused knowledge sources. More content can reduce precision, introduce stale evidence, and increase governance burden. A healthy knowledge layer is curated: sources are added for a reason, measured for usefulness, and retired when they stop supporting the agent’s job.<\/p>\n
Source onboarding should include a quality review. Check whether documents are current, searchable, consistently titled, permissioned correctly, and free of obvious duplicates before adding them to an agent. Poor source quality is easier to fix before users depend on the answers.<\/p>\n
Measure knowledge performance through unanswered questions, low-confidence cases, citation quality, and repeated user corrections. Those signals can reveal missing content or weak source boundaries even when the agent has many documents attached.<\/p>\n
When a knowledge source is retired, remove its connection and verify that the agent no longer cites or relies on cached versions. Content lifecycle should include deletion as well as addition.<\/p>\n
Knowledge architecture should also document whether a source is primary, supplementary, or public reference material. That distinction helps reviewers understand how much authority an answer derived from that source should carry.<\/p>\n
Knowledge-source boundaries should be explained to users where they affect expectations. An HR policy agent may answer only from approved HR repositories, while a broader research agent may use public sites as well. Clear scope reduces false assumptions about what the agent \u201cknows.\u201d<\/p>\n
Use source-specific evaluation cases. Ask questions that should be answered by SharePoint, Dataverse, uploaded content, and public websites separately so failures can be traced to the responsible source type rather than one generic knowledge score.<\/p>\n
When several sources answer the same topic, compare their update process and governance. The technically easiest source to connect is not always the right source to trust. A well-managed SharePoint library may be better than an uploaded PDF that nobody owns, and a live Dataverse record may be better than a nightly export.<\/p>\n
Knowledge maintenance should be part of the agent owner’s calendar. Review source health, permissions, stale content, and unanswered questions on a recurring cadence so the knowledge layer remains aligned with the business process.<\/p>\n
Source cleanup should be measurable. Track duplicated documents, stale versions, missing owners, failed refreshes, and unanswered high-value questions. These indicators help content teams improve the corpus systematically rather than reacting only when a user reports a bad answer.<\/p>\n
Knowledge owners should also review search language. Users may ask with acronyms, product nicknames, customer terminology, or outdated names that do not appear in official documents. Adding useful synonyms, clearer titles, or better structure to the source can improve retrieval more reliably than adding prompt instructions that guess what the user meant.<\/p>\n
Knowledge-source changes should pass through lightweight change control for important agents. Adding a new repository can change answer behavior as much as editing instructions because the retriever now has different evidence to rank. Record the change, run representative queries, and keep the previous source configuration until quality is understood.<\/p>\n
Keep that source-change history available to support and governance teams.<\/p>\n
Review sources regularly.<\/p>","protected":false},"excerpt":{"rendered":"
Knowledge sources determine what a Copilot Studio agent can retrieve when it needs factual context beyond its instructions. Current Copilot Studio supports several knowledge types, including public websites, uploaded documents, SharePoint, and Dataverse, with different authentication and scale characteristics. Choosing a source is therefore a data-architecture decision rather than a simple content-upload step. The most useful knowledge source is the one that is authoritative, permissioned correctly, fresh enough for the task, and structured so retrieval can find the right evidence. More sources do not automatically produce better answers. Knowledge design…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2226,2182],"tags":[],"class_list":["post-11600","post","type-post","status-publish","format-standard","hentry","category-ai-machine-learning","category-microsoft"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t