Copilot Studio knowledge sources ground answers in selected content. Use SharePoint for permission-aware organizational documents, Dataverse for governed business records, and public websites for published information. The important design decisions are source scope, end-user identity, content ownership and evidence that the answer is supported.
Key takeaways
- Choose a source by its information and access model, not convenience alone.
- Test with ordinary users, including people who must not receive a particular answer.
- Separate finding information from executing a business action.
- Record the agent experience and orchestration mode before following configuration instructions.
SharePoint vs Dataverse vs public website content
For a fictional equipment-support assistant, approved operating instructions could live in SharePoint, service records in Dataverse, and public product guidance on a website. Those are different authorities. A public marketing page should not override an approved internal procedure or determine whether a particular customer has an active contract.
| Source | Good candidate information | Decision to resolve |
|---|---|---|
| SharePoint | Approved procedures, policies and operating documents | Which library or folder and which users? |
| Dataverse | Business records with a defined table and access model | Which tables and record permissions? |
| Public website | Published product documentation or service information | Which indexed public scope is authoritative? |
Microsoft’s knowledge-source overview distinguishes source types and orchestration modes. Knowledge can be configured at the agent level or within a generative answers node. Exact availability and limits depend on the selected experience; capture those details in the implementation record rather than copying an old limit table.
Keep the initial scope narrow. Start with one approved knowledge domain and a named content owner. Adding every repository makes conflict resolution, testing and ownership harder. Expand when the first domain has a reliable review process.
A permission-aware retrieval architecture
Question + signed-in user + selected agent channel
↓
Knowledge source selection
↓
Approved source scope and access boundary
├─ SharePoint documents
├─ Dataverse business records
└─ Public website content
↓
Retrieved evidence → grounded answer + citations
↓
User review or supported handoff
Business write/action → separate authorized tool and validation pathThis diagram is an implementation review model, not a claim about internal service execution order. A source description helps explain when information is relevant; it is not an authorization control. A generated citation is evidence to inspect, not permission to perform a transaction.
For example, an assistant may explain an equipment-return procedure. Approving a return, changing a customer record or issuing a refund requires a separately designed action path. Define who can execute that action and what validation is required.
Preserve provenance in the user experience. A reviewer should be able to identify the supporting source and recognize when the agent does not have enough information. Do not make an answer look like an approved business decision simply because it is fluent.
A practical configuration worksheet
The following is a proposed configuration record for a pilot, not an exported Copilot Studio schema or a tested tenant configuration. It makes the intended scope reviewable before deployment.
Agent purpose: explain approved equipment-support procedures
Experience / orchestration: record actual selected configuration
Channel: record intended production channel
Source name: approved-equipment-procedures
Source location: approved library or folder reference
Source owner: named operations content owner
Description: procedures for equipment returns and service triage;
excludes commercial contract decisions
Audience: approved employee groups, validated with test users
Freshness check: owner and review date for each procedure
Fallback: explain missing evidence and offer the support route
Acceptance evidence: answer, citation, user identity and test caseSharePoint setup
Microsoft’s SharePoint integration guidance describes adding a SharePoint source and configuring user authentication. The native integration surfaces content according to the chatting user’s permissions. Scope it to the intended site or folder; test access with the actual audience. Do not assume a successful maker test proves every employee’s access.
Document which SharePoint ingestion option you selected. Connecting a SharePoint knowledge source and adding individual files through an upload route are different implementation choices. Review their supported behavior before treating them as interchangeable.
Dataverse setup
The Dataverse knowledge-source documentation requires Dataverse search and Microsoft authentication for the documented standard experience. Select only the relevant tables, use clear descriptions, and verify underlying data permissions. The newer agent experience has different configuration guidance; record the experience before applying instructions.
Translate business vocabulary into the data model during testing. A user may say “open repair” while the system uses a different table or status name. Maintain an approved terminology record and follow the configuration mechanisms supported by the selected experience.
Public website setup
Microsoft’s public-website guidance describes grounding through Bing search, with URL-scope and indexing requirements. An authenticated internal site is not a public website knowledge source. Verify the chosen public pages can be retrieved and contain current, useful text.
Separate a configured website source from broader web-search behavior. Decide deliberately whether answers may draw on information outside the approved public scope. Record that decision in the test cases.
Permission inheritance needs negative tests
Use at least two ordinary test identities: one with legitimate access to a restricted document and another without it. Ask equivalent questions in separate conversations. Test both direct requests and indirect prompts that could reveal restricted content through summaries or comparisons.
Do not solve a missing answer by broadening production permissions until the cause is understood. The problem may be a wrong source location, unsupported content, an outdated configuration or a channel-specific authentication issue. A broader grant can conceal the defect while increasing exposure.
Test membership removal and content reclassification too. Confirm what happens after access changes using the platform’s supported behavior and documented propagation expectations. Keep evidence of the expected result, not a guessed immediate-revocation guarantee.
See the Dataverse access-control guide for roles, teams and record boundaries. Data access remains a separate concern from whether someone can open the agent.
An answer-quality and grounding test plan
| Test | Expected evidence | Failure signal |
|---|---|---|
| Known approved procedure | Correct answer with a supporting source | Unsupported steps or wrong procedure |
| Restricted procedure, unauthorized user | No restricted information disclosed | Quotation or summary reveals it |
| Question outside source scope | Clear fallback or approved handoff | Confident invented policy |
| Conflicting old and current documents | Owner resolves authority and content scope | Agent silently blends incompatible rules |
| Action request | Approved authorized action path or explanation | Knowledge answer implies a transaction occurred |
| Published channel | Authentication, citations and fallback remain usable | Only the maker test works |
Build the evaluation set from real question types, but use sanitized records. Include paraphrases, abbreviations, incomplete questions and follow-ups. Have the content owner define the expected answer or acceptable boundary before looking at generated results.
Score correctness, source support and access behavior separately. An answer can be factually correct yet unsupported by the approved source. It can also be grounded in a document the intended audience should not receive. Both need investigation.
No production tenant was deployed or measured for this guide. These are proposed acceptance tests and configuration artifacts, not reported customer outcomes.
Troubleshoot missing and unreliable answers
- Maker succeeds, employee fails: compare identity, permissions and published channel configuration.
- Right topic, wrong source: review source descriptions, conflicting material and scope.
- Source looks ready but answer is absent: test a simple known question and inspect supported content and access requirements.
- Public page is missing: check URL eligibility, redirects and indexing instead of treating the website as a direct database query.
- Answer changes after publication: compare configuration, content versions and channel behavior before changing several settings together.
For operations, assign owners for content updates, access review and agent release. Re-run the important tests after source changes. Keep a small, auditable change record that connects configuration, test evidence and publication.
Common questions
How does Copilot Studio retrieve answers from SharePoint?
It searches the configured SharePoint knowledge scope under the configured authentication context and generates an answer from retrieved content. With the documented native integration, results respect the chatting user’s permissions.
Should I use SharePoint or Dataverse as a knowledge source?
Choose SharePoint for governed documents and Dataverse for relevant business records. Base the decision on source authority, access requirements and the questions users need answered.
Can a private website be added as a public website source?
No. The public website route requires supported publicly accessible, indexed content. Use an appropriate authenticated source design for private information.
Does adding knowledge let an agent update business records?
Retrieval and business actions are different designs. Record changes need an authorized tool or action path with validation and appropriate permissions.
What should be tested before publishing a knowledge agent?
Test correct answers, citations, denied access, conflicting content, fallback behavior and the actual published channel with ordinary user identities.
Plan a grounded assistant around trusted information
Bring the source inventory, intended audience and a small set of real question types. Plan a Power Platform implementation with an explicit access model and repeatable answer tests.