Copilot connectors

No prebuilt Copilot connector for your system? Check this before you build custom

You checked the connectors gallery, and your system is not in it. Documentum. iManage. An OpenText archive. An on-premises SharePoint farm nobody wants to talk about. So the plan forms: we will have to build a custom connector.

Stop for a moment. Between “Microsoft does not have one” and “we build our own” sits a step most people skip entirely, and it very often ends the search before it starts.

A connector can come from three places, not two

There are really three sources of a Copilot connector. There are the hundred-plus Microsoft-built ones in the gallery. There is custom development, which you own forever. And sitting quietly between them is the one people forget: the partner-built gallery.

The gallery people skip

Microsoft maintains a separate gallery of connectors built and supported by partners. These are not Microsoft’s connectors. They are developed, licensed and supported by the partner, and the support models vary from one to the next. Some carry a Certified for Microsoft 365 Copilot badge, which means Microsoft validated them for consistent retrieval behaviour across Copilot and Search.

The publishers are the names that have spent years in enterprise search: BA Insight, now part of Upland; RheinInsights; Accenture, with its Aspire connectors; ServiceNow; and the source vendors themselves. You find the connector in the gallery, then go to the partner to license and deploy it.

The range is wider than you think

And it covers far more than the Microsoft-built list. Between the partners, the gallery reaches Documentum, iManage, NetDocuments, OpenText Livelink, IBM Content Manager, Elasticsearch, on-premises SharePoint from 2013 through Subscription Edition, Notion, Slack, Trello, Google Drive, and a long list beyond. If your source is a mainstream enterprise system, the odds are good that someone has already built, and now maintains, a connector for it.

The example everyone reaches for

Take Documentum, the one people always name. There is no Microsoft-built Documentum connector. But there are several partner ones: BA Insight ships a Documentum connector and a Documentum Cloud connector, and Accenture’s Aspire has a Documentum DQL connector, with more vendors beyond.

Here is why that matters more than it first looks. The genuinely hard part of a Documentum connector is mapping Documentum’s permission model onto Graph ACLs, so that Copilot only ever surfaces content to the right people. The partner has already solved that, and maintains it. That is precisely the ownership burden I warned about with custom connectors, handed to a company whose whole business is carrying it.

If nobody has built it, is Microsoft about to?

When no connector exists yet, the next question is whether one is coming. Three places tell you:

  • The Microsoft 365 Roadmap, where you can filter for Copilot connectors and see what is planned or rolling out.
  • The connectors gallery in your own admin center, where connectors in the Admin Preview state are the live preview pipeline, arriving before general availability.
  • The monthly “What’s New in Microsoft 365 Copilot” posts, where new connectors are announced as they ship.

The catalogue grows every quarter, so a source missing today may be a click away in two.

The honest catches with partner connectors

Partner connectors are not free of trade-offs, and you should go in clear-eyed. You are taking a dependency on a third party: their price, their support quality, their release cadence, their survival. Support models vary, so read what you are actually getting. Favour the ones certified for Copilot where you can. And because the connector is doing the ACL mapping on your behalf, validate that it gets the permissions right before you trust it in front of Copilot, the same scrutiny you would give your own code.

With those checks done, a partner connector is almost always the better deal than building and owning your own.

The order to work through

So the search order is not “Microsoft-built, then custom.” It is four steps:

  1. Microsoft-built — the hundred-plus in the gallery.
  2. Partner-built — the gallery people skip.
  3. Roadmap and preview — wait, if something is close.
  4. Custom — only when the source is genuinely unique to you.

Custom belongs at the bottom of that list, not second on it.

The instinct to build is a developer’s instinct, and it is often the expensive wrong turn. Before you scope a project to connect some system to Copilot, spend an hour in the partner gallery. The connector you were about to spend a quarter building, and then own for as long as the source exists, may already be sitting there, maintained by a company whose entire job is to maintain it. Build last, not second.

August 3, 2026 by Copilot Microsoft 365 0

Custom vs prebuilt Copilot connectors when to actually build your own

Sooner or later, the prebuilt catalogue runs out. You go looking for a connector to bring some system into Copilot, and it is not there  because the system is homegrown, or niche, or something a vendor built for you a decade ago. Now you have a choice: build a custom connector, or find another way in. Having built several, here is how I decide  and it is not the question most people start with.

Two paths, and where the cost hides

There are two ways to get external content into Copilot. A prebuilt connector, which you configure in the admin center with credentials and a schedule while Microsoft’s service does the work. And a custom connector, which is a software project: a developer defines a schema, registers an app in Microsoft Entra ID, and writes code to pull content from the source and push it into the Microsoft Graph through the connectors API.

The first is configuration. The second is development. That distinction is where people underestimate the cost.

The build is not the expensive part

Writing a custom connector is not, honestly, that hard for a competent developer. The schema, the app registration, the crawl-and-push code  you can stand up a working connector in a sprint. That is why “can we build it?” is the wrong question to lead with. You almost always can.

The expensive part is not the build. It is the ownership.

What ownership actually means

A prebuilt connector, Microsoft owns forever. When the source’s API changes, they fix it. When throttling limits shift, they handle it. When the schema needs a new field, they ship it.

A custom connector, you own all of that, indefinitely:

  • the incremental crawl logic, so you index only what changed instead of re-crawling the world every night;
  • throttling and retry, so a large source does not rate-limit you into failure;
  • error handling and monitoring, so you know when it silently stops;
  • keeping up with the connectors API as it evolves;
  • and the mapping of the source’s permissions onto Graph ACLs.

That last one deserves its own paragraph, because it is where custom connectors most often go wrong.

The ACL mapping is the hard bit

The whole point of a connector is that every item it indexes carries an access control list, so Copilot only ever surfaces content to the people who should see it. For a prebuilt connector, Microsoft worked out how the source’s permission model maps onto Graph ACLs, and maintains that mapping. For a custom one, you do.

And it is genuinely hard. You have to translate the source system’s groups, roles and sharing into the identities and ACLs the Graph understands — correctly, for every item. Get it too loose and you have just overshared a whole new system into Copilot. Get it too tight and the content is invisible and the connector is pointless. There is no forgiving middle where “roughly right” is fine, because Copilot will faithfully honour whatever ACLs you hand it.

On-premises: the connector agent

If the source lives on-premises, behind the firewall, there is a specific piece to know about: the Microsoft Graph connector agent. It is a Windows service you install on a server inside your network that acts as the secure bridge between your on-prem data and the connector APIs.

Two practical facts shape your design. One agent instance is recommended for up to three connections before performance degrades. And the agent authenticates through an app you register in Entra ID which brings us to the lesson that is never in the quick-start.

The gotcha that takes things down quietly

That Entra app authenticates with either a client secret or a certificate. Client secrets expire.

When the secret behind your connectors expires and nobody renewed it in time, every connection that relies on it stops indexing at once. It is a silent outage: nothing errors in anyone’s face, the content just quietly goes stale, and you find out weeks later when someone asks why Copilot no longer knows about last month’s tickets.

Two things save you. Use a certificate rather than a client secret, because it can be valid for years instead of months. And whichever you use, put the expiry in a calendar with a reminder well ahead of the date, because a connector platform gives you no grace period. This is exactly the class of expiry that takes down more than you expect, precisely because a single shared credential can sit behind several connections at once.

The decision is not “can we”

So the question is not “can we build it.” You almost always can. The question is “do we want to own it.”

Use a prebuilt connector whenever one exists every time because the maintenance you are handing to Microsoft is the expensive, unglamorous, never-ending part. Build custom only when two things are both true: the source genuinely is not supported, and it matters enough to justify owning a piece of indexing infrastructure for as long as the source exists.

And bear in mind the catalogue only grows. Every quarter, Microsoft and its partners add connectors, which means the set of sources that truly need custom work shrinks every year. Build custom for the genuinely unique the systems only your organization runs. For everything else, the out-of-the-box connector is the better deal. Not because it is easier to start, but because someone else carries the weight you would otherwise carry forever.

August 3, 2026 by Copilot Microsoft 365 0

Copilot connectors (formerly Graph connectors) the 100+ you get out of the box

Copilot is only as useful as the content it can reach. Out of the box, it reaches your Microsoft 365 — SharePoint, mail, Teams. But most organisations’ knowledge does not all live in Microsoft 365. It is in ServiceNow, in Salesforce, in a Confluence wiki, on a file share, in some homegrown app the finance team relies on. Copilot connectors are how you bring that content in. And before you assume that means a development project: Microsoft ships more than a hundred of them, ready to configure without a line of code.

First, the name changed

What used to be called Microsoft Graph connectors are now Microsoft 365 Copilot connectors. Same technology, a new label that reflects where the content ends up. A connector defines a connection to an external system and brings its content into Microsoft 365, so that Copilot and Microsoft Search can reason over it alongside your SharePoint sites and email.

Two kinds: synced and federated

There are two flavours, and the difference matters.

Synced connectors crawl the source and index its content into Microsoft Graph, so it becomes part of your search index. They are organisation-wide and configured by an admin.

Federated connectors do not index anything. They fetch results live from the source at query time, over the Model Context Protocol, which suits sensitive or fast-changing data you would rather not copy into Microsoft 365. They are per-user, and the user authenticates to the source themselves.

Most of the classic “get our other system into Copilot” scenarios are synced. That is the model the rest of this covers.

The hundred-plus you already have

Here is the part that saves you a development budget. Microsoft and its partners ship over a hundred prebuilt connectors, and between them they cover most of what a typical organisation runs:

  • Files and content: Box, Dropbox, Google Drive, Confluence, MediaWiki, network file shares
  • Enterprise apps and databases: Salesforce, ServiceNow, Dynamics 365, SAP, SQL and Oracle databases, Azure services
  • And a long tail beyond: Workday, Zendesk, Jira, and more

To use one, you pick it in the Microsoft 365 admin center, give it credentials and a bit of configuration, and Microsoft’s connector service handles the crawling and indexing from there. No schema to define, no code to write, no app registration to build. Microsoft and its certified partners maintain and update them. You will need the AI administrator role to set them up.

How a synced connector actually works

Under the hood, a synced connector ingests each item into the Microsoft Graph index with three things attached: the content, its metadata such as title and URL, and — the important one — an access control list.

That ACL is what makes the whole thing safe. Copilot and Search only ever show a connector item to users who have permission to it in the source system. The connector also keeps itself current, periodically checking the source for new, changed and deleted content on a schedule you control. The indexing pipeline runs in Microsoft’s cloud, and the content is stored in your own tenant.

Where the content shows up

Once a connector is running, its content appears in the places your users already work:

  • In Copilot Chat, where a question like “summarise the Contoso deal” can pull the answer from a connected Salesforce record and cite it, without the user ever opening Salesforce.
  • In Copilot Search, which includes connector content automatically, with no extra setup.
  • In Microsoft Search across Office.com, SharePoint, Outlook, Teams and work Bing, where external results appear alongside internal ones, each labelled with its source.
  • As a knowledge source for custom agents you build in Copilot Studio.

The point of a connector is that the knowledge stops being trapped in a system nobody thinks to open.

When out of the box is not enough

Microsoft’s own rule of thumb is the right one: use a prebuilt connector whenever one exists, and reserve custom development for the sources that genuinely need it.

A custom connector is a real project. A developer defines a schema, registers an app in Microsoft Entra ID, and writes the code to pull content from the source and push it into the Graph. That is the right call for a homegrown or unusual system with no prebuilt option — I have built several for exactly that reason. But if your source is one of the hundred-plus already in the gallery, building your own is effort you do not need to spend. For on-premises sources, there is a middle path: the Microsoft Graph connector agent indexes local content without exposing it to the internet.

The permissions catch

One thing worth flagging, because it is the same lesson as everywhere else Copilot reaches. A connector respects the source’s permissions through that per-item ACL, which is exactly what you want. But it also faithfully reproduces the source’s oversharing. If a Confluence space or a file share is open to everyone, the connector will index it that way, and Copilot will surface it to everyone — just as it does for an overshared SharePoint site. The connector is not the exposure. The source’s permissions are. Get those right before you index, not after.

So before you assume that getting your other systems into Copilot means a development budget, open the connectors gallery in the admin center and look. There is a good chance the system you had in mind is already there, waiting for credentials and a crawl schedule. Start with what is out of the box, and build custom only for what genuinely is not.

The Copilot connectors gallery in the Microsoft 365 admin center, showing prebuilt connectors by category (Azure DevOps, Confluence, ServiceNow, Jira, and more) with Add buttons.

August 3, 2026 by Copilot Microsoft 365 2

Start Here

PnP PowerShell for SharePoint Admins
The scripts, in reading order

What Copilot Chat (Basic) Can Do
Where the free tier stops

About this site
Who writes it and how it is tested