Back to Blog

Adding Knowledge Sources to Microsoft 365 Copilot Declarative Agents - A Practical Guide

March 17, 2026•8 min read•Michael Ridland

One of the most common questions we get from Australian enterprise clients is "how do we make Copilot actually know about our stuff?" They've seen the demos, they're paying for the licences, but Copilot keeps giving generic answers because it doesn't have access to the right internal data.

The answer is declarative agents with properly configured knowledge sources. Microsoft has quietly built a solid system for scoping what data your custom agents can access, and once you understand the configuration, it opens up some genuinely useful scenarios. The official Microsoft documentation on adding knowledge sources walks through every option, but let me share what actually matters when you're deploying this for real.

What Are Knowledge Sources in This Context?

Declarative agents in Microsoft 365 Copilot are custom agents you define through a JSON manifest. Think of them as Copilot with guardrails - you tell it what persona to adopt, what instructions to follow, and critically, what data it can access.

Knowledge sources are the data your agent uses to generate answers. Without them, your agent is just base Copilot with a custom system prompt. With them, it can pull from your SharePoint sites, Teams conversations, emails, people directory, web search results, and data ingested through Copilot connectors (formerly Graph connectors).

The configuration lives in the declarativeAgent.json file inside your app package. Each knowledge source gets added to a capabilities array with specific settings.

Web Search - The Easy Win

Adding web search is the simplest capability to configure:

"capabilities": [
  {
    "name": "WebSearch"
  }
]

That's the entire configuration. Your agent now searches the web when it needs information.

But here's where it gets interesting for enterprise use. You can optionally scope the web search to specific domains. For a client in the insurance sector, we scoped web search to regulatory body websites, industry publications, and their own public-facing site. The agent could pull in current regulatory updates without risking it surfacing competitor information or irrelevant content.

I'd recommend always scoping web search when you're building agents for professional use. Unscoped web search means your agent might cite random blog posts or outdated information, which undermines the trust your users need to have in the tool.

SharePoint and OneDrive - Where the Real Value Lives

For most of our Microsoft AI consulting clients, SharePoint is where the gold is. Policy documents, SOPs, project files, client records - it's all sitting in SharePoint libraries.

The configuration points to specific sites, libraries, folders, or even individual files:

{
  "name": "OneDriveAndSharePoint",
  "items_by_url": [
    {
      "url": "https://contoso.sharepoint.com/sites/ProductSupport"
    }
  ]
}

A couple of things I've learned deploying this:

Be specific with your URLs. You can point at an entire site, a document library, a folder, or a single file. The more targeted you are, the better your agent's responses will be. An agent that searches through 500,000 documents across your entire SharePoint tenant will give worse answers than one pointed at the 200 documents that actually matter for its purpose.

Omitting items_by_url gives access to everything. If you don't specify URLs, the agent can search all OneDrive and SharePoint content available to the logged-in user. That might sound convenient, but it means your agent's quality depends entirely on how well your SharePoint is organised. For most companies, that's not great.

Pro tip: Use the "Copy direct link" feature in SharePoint to get exact paths. Right-click on a file or folder, select Details, and copy the path from there. Getting the URL wrong is one of the most common setup mistakes we see.

Teams Messages - Tapping Into Conversational Knowledge

This one caught me off guard the first time I used it. You can give your agent access to Teams channels, team conversations, meeting chats, and even 1:1 messages.

{
  "name": "TeamsMessages",
  "urls": [
    {
      "url": "https://teams.microsoft.com/l/team/..."
    }
  ]
}

For a professional services firm we worked with, we built an agent that could search their project delivery channels. When a consultant asked "how did we handle the data migration for the ANZ project?", the agent could pull relevant discussion threads from the Teams channel where that work was coordinated.

The practical value here is that so much institutional knowledge lives in Teams messages and never makes it into formal documentation. This capability surfaces that knowledge.

Same as SharePoint, omitting the urls array gives access to all Teams content available to the user. I'd recommend scoping this carefully. You probably don't want your project planning agent reading the Friday drinks channel.

People Knowledge - The Overlooked Source

The People capability lets your agent answer questions about individuals in your organisation:

{
  "name": "People"
}

Simple configuration, surprisingly useful output. "Who's the best person to talk to about Azure networking?" or "Who has experience with SAP integrations in the Melbourne office?" - these are questions that typically require bugging three different people before someone points you in the right direction.

This pulls from the Microsoft Graph people data - profiles, org charts, skills, recent collaborations. The quality depends on how well your organisation maintains profile information, which varies wildly. If your people profiles are sparse, this capability won't add much.

Email Knowledge - Handle With Care

You can scope agents to search the user's mailbox or shared mailboxes:

{
  "name": "Email",
  "folders": [
    {
      "folder_id": "inbox"
    }
  ]
}

The folders array lets you limit access to specific folders. You can also configure shared mailbox access by adding a shared_mailbox property with the email address.

This is powerful but warrants thoughtful implementation. For a shared mailbox that handles customer enquiries, we built an agent that could search past interactions to help support staff find precedents. That's a clear, scoped use case.

For personal mailboxes, the privacy implications need serious consideration. Users need to understand that the agent is searching their email, and the use case needs to justify the access. Most of our deployments limit email access to shared mailboxes for exactly this reason.

Copilot Connectors - Bringing External Data In

Copilot connectors (the rebranded Graph connectors) let you ingest data from external systems into the Microsoft Graph, making it searchable by your agents:

{
  "name": "GraphConnectors",
  "connections": [
    {
      "connection_id": "policieslocal"
    }
  ]
}

This is how you connect data from systems outside the Microsoft 365 ecosystem. CRM data, ERP records, custom databases, third-party SaaS platforms - if you've set up a Copilot connector to ingest that data, your declarative agents can search it.

The connector ID is something you'll need to look up in your Microsoft 365 admin centre. Microsoft's documentation on retrieving capability IDs covers the process.

We've used this to build agents that can answer questions across ServiceNow tickets, Dynamics 365 records, and internal wikis hosted outside SharePoint. The setup for the connector itself is more involved than the agent configuration, but once it's running, the agent-side integration is straightforward.

Combining Knowledge Sources

The real power comes from combining multiple sources. A single agent can have web search, SharePoint access, Teams messages, and connector data all configured simultaneously:

"capabilities": [
  { "name": "WebSearch" },
  {
    "name": "OneDriveAndSharePoint",
    "items_by_url": [
      { "url": "https://contoso.sharepoint.com/sites/Policies" }
    ]
  },
  {
    "name": "TeamsMessages",
    "urls": [
      { "url": "https://teams.microsoft.com/l/team/..." }
    ]
  },
  { "name": "People" }
]

We've built agents for Australian financial services organisations that combine policy documents from SharePoint, regulatory updates from scoped web search, and discussion threads from Teams. A compliance officer can ask a single question and get an answer that synthesises across all these sources.

What to Watch Out For

Permissions still apply. Knowledge sources don't bypass Microsoft 365 security. If a user doesn't have access to a SharePoint site, the agent won't return content from it. This is a feature, not a limitation, but you need to account for it in your design.

Quality depends on source quality. Agents can only be as good as the data they access. We've seen deployments fail not because of technical issues but because the SharePoint sites were full of outdated, duplicated, or poorly named documents. Do a content audit before you build the agent.

Keep knowledge sources focused. More data doesn't mean better answers. Each source you add increases the search space and can dilute response quality. Build purpose-specific agents rather than one agent that knows everything.

Getting Started

If you're exploring Copilot extensibility for your organisation, start with a single, well-defined use case and a targeted set of knowledge sources. A support agent with access to your knowledge base SharePoint site is a better first project than an "everything agent" that tries to search the entire tenant.

At Team 400, we help organisations across Australia design and deploy Copilot Studio solutions and custom declarative agents. The knowledge source configuration is the part that makes or breaks these deployments, and getting the scoping right requires understanding both the technology and how your organisation's data is structured.

For more details on all the configuration options and the full manifest specification, check the official Microsoft documentation. It's well-maintained and includes examples for every knowledge source type.

If you're ready to explore what Copilot extensibility could look like for your team, reach out. We've done enough of these deployments to know what works and what wastes your time.