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.