How to Add a Custom Data Source with Microsoft Copilot Connectors

Official documentation checked October 14, 2026.

Microsoft Copilot connectors can bring information from an external business system into organizational Copilot experiences. The correct setup depends on whether you want to index the content or query the source when a user asks a question. Those are different connector models, not interchangeable options in one universal setup wizard.

This guide explains how to choose a route and what to prepare. A production connection also requires a data owner, an authorization design and a tested way to keep information current.

Choose a synced or federated connector

Synced connectors ingest external content into Microsoft Graph for supported search and Copilot experiences. Federated connectors retrieve information from a source through a supported connection rather than following the same indexing workflow. Current custom federated setup uses a Model Context Protocol (MCP) server. See Microsoft’s connector overview.

Start with these decisions:

• Is there an existing Microsoft or partner connector for this repository? Read its authentication, licensing and permission-mapping requirements before building anything.
• Does the task require a searchable document collection or a query against information that changes frequently?
• Which users may access each record, and how will that restriction be enforced?
• Who will monitor expired credentials, source changes and failed updates?

A prebuilt connector still needs configuration. A custom connector does not universally require a publicly exposed REST endpoint, source-system write permission or certification before internal use. Requirements depend on the selected route; do not open a private repository to the internet simply to follow an assumed prerequisite.

Build a custom synced connection with Microsoft Graph

For a source without a suitable prebuilt connector, the Microsoft Graph connectors API provides the ingestion path. This is a development task, not a promise that an administrator can upload any API description and finish in 15 minutes.

1. Register the application and obtain the required API permissions through your organization’s approval process.
2. Create an external connection with a stable identifier and meaningful description.
3. Register the schema for the properties you will ingest. Schema registration is asynchronous; check its operation status before proceeding.
4. Send external items with their properties, searchable content and access-control lists.
5. Implement updates, permission changes and deletions so that the indexed representation follows the source.

Begin with a small collection containing both broadly readable and restricted test items. Verify the source-to-index field mapping and authorization separately. Do not grant everyone access to simplify a failed test.

Configure a custom federated MCP connection

Microsoft’s custom federated connector instructions require an MCP server exposing read-only tools, such as search, fetch or query, and suitable administrative access. Prepare authentication first: supported choices include Microsoft Entra SSO and OAuth 2.0, with registration steps through the Teams Developer Portal. A no-authentication option is not appropriate for confidential information that needs user authorization.

1. In the Microsoft 365 admin center, open Copilot > Connectors > Gallery.
2. Under Created by your org, choose Create a new connector, then add a custom connector using Connect to MCP server.
3. Supply the display name, server base URL and the authentication registration information required for your chosen method.
4. Save the connector and initially scope deployment to the intended test users or groups.

Confirm the current tenant’s availability and prerequisites before scheduling deployment. Application registration and consent should be reviewed; keep credentials out of articles, screenshots and support tickets.

Test permissions and freshness before wider rollout

Ask a question with a known answer and inspect the cited record. Then test a user who must not access that record. Repeat after changing the source content and after revoking access. These tests answer different questions; one convincing response is not an end-to-end acceptance test.

For failures, preserve the error, connection identifier, timestamp and affected source item. Check authentication, source availability, permissions and ingestion status before rebuilding anything. Microsoft’s connection management guide explains the available status and visibility controls. Pausing a synced connection does not necessarily remove previously indexed content.

Avoid deleting and recreating a connection as the default repair. First determine whether the problem is configuration, source access or stale data, then choose a scoped correction with a rollback plan.