How to Add Knowledge Sources in Microsoft Copilot Studio

Knowledge sources let a Microsoft Copilot Studio agent answer with information from approved websites, documents, business data, and connected systems. You can add knowledge while creating an agent, from the agent's Overview or Knowledge page, or inside a topic's generative answers node.

The available source types depend on the Copilot Studio experience, environment, licensing, region, and preview access. Use the options shown in your Add knowledge dialog as the source of truth for your tenant.

Agent-level versus topic-level knowledge

Scope	Use it when	Where to configure it
Agent level	The source should be available across the agent's conversations	Overview or Knowledge page
Topic level	A source is relevant only to a particular flow or answer step	Properties of a generative answers node in the topic

Do not add every available document at the agent level. A smaller, well-scoped knowledge set usually makes ownership, testing, and troubleshooting easier.

Add knowledge while creating a new agent

During the agent-creation conversation, you can describe the agent and provide a public website or SharePoint URL when that option is supported. Copilot Studio adds the source to the new agent, where you can review it after creation.

1. Start creating an agent in Copilot Studio.
2. Describe the agent's role and the information it should use.
3. Provide the public website or SharePoint location requested by the creation experience.
4. Finish creating the agent.
5. Open the Knowledge page and confirm the source, status, name, and scope before testing.

Creation-time prompts are convenient, but they do not replace source review. Confirm that the URL points to the intended content and that the source does not expose information the target audience should not receive.

Add knowledge to an existing agent

1. Open the agent in Copilot Studio.
2. Go to Overview or Knowledge.
3. Select Add knowledge.
4. Choose one of the source types available in your environment.
5. Authenticate or provide the URL, file, table, index, or connection details requested for that source.
6. Enter a unique, descriptive name and a precise description.
7. Select Add to agent, then wait until the source reports that it is ready if indexing is required.
8. Test representative questions and inspect the returned citations before publishing.

Microsoft's current instructions are available in Add knowledge to an agent.

Choose the right source type

Source	Good use case	Important check
Uploaded files	A controlled set of policies, manuals, or reference documents	Supported format, size, version, and duplicate content
Public website	Public product documentation, help pages, or FAQs	URL scope, crawl accessibility, and content ownership
SharePoint	Internal documents and lists governed by Microsoft 365 permissions	User access and whether the chosen site or list is too broad
Dataverse	Structured business records and tables	Table selection, terminology, and security roles
Azure AI Search	Large enterprise indexes with an existing search design	Index schema, freshness, filters, and authentication
Copilot or Power Platform connector	Content in supported external business systems	Preview status, connection identity, data policy, and runtime permissions

Some real-time Power Platform connectors are preview features. Microsoft says these connections authenticate runtime calls with the requesting user's token, but administrators should still validate source permissions, data policies, and preview limitations before production use. See the current knowledge sources summary for supported options.

Add knowledge to a topic

Topic-level knowledge is useful when a particular generative answer should search a defined source rather than the agent's general collection.

1. Open the relevant topic.
2. Add or select a generative answers node.
3. Open the node's properties.
4. Add or select the source for that node.
5. Test questions that should use the source and questions that should not.

Keep the scope intentional. If several topics need the same source, agent-level knowledge may be simpler; if the source should affect only one workflow, topic-level configuration reduces accidental retrieval elsewhere.

Write names and descriptions that help orchestration

Each source should have a unique name that identifies both its content and owner, such as HR leave policy — Global People Operations. Avoid names such as Documents or Website 2.

The description should state:

• what the source contains;
• which questions it should answer;
• the audience, region, product, or date range it covers;
• important exclusions or a more authoritative source for nearby topics.

Example: “Approved North America employee leave policies and eligibility rules. Use for leave types, application steps, and manager responsibilities. Do not use for payroll-tax questions or employees outside North America.”

Use suggested knowledge sources carefully

The See suggestions option may offer sources used in your previous agents, agents shared with you, or relevant Microsoft 365 work. Availability and supported source types can change.

Treat a suggestion as a shortcut, not an approval decision. Before adding it, confirm the owner, content scope, permissions, freshness, and intended audience. Copied or reused source configurations still need testing in the new agent.

Test before publishing

Build a small test set with expected answers and citations:

• questions answered directly by each source;
• questions that require distinguishing between two similar sources;
• out-of-scope questions the agent should decline or route elsewhere;
• requests from users with different source permissions;
• questions about recently updated content;
• ambiguous wording and common misspellings.

Check whether the response is supported by the cited material, not merely whether it sounds plausible. If retrieval is weak, narrow the source scope, improve its name and description, remove duplicates, or move specialized material to a topic-level node.

Security and maintenance checklist

• Use the least data necessary for the agent's job.
• Confirm source-system permissions with real test users.
• Do not upload secrets, credentials, or unapproved personal data.
• Record the source owner and review date.
• Remove superseded files instead of leaving conflicting versions active.
• Re-test after changing a source, authentication method, topic, or agent instructions.
• Publish only after citations and access behavior are correct.

A well-grounded Copilot Studio agent depends less on the number of sources than on careful scope, clear descriptions, correct permissions, and repeatable testing.