By now you've met Copilot's grounding (4.1), built an agent (4.2), scoped a Notebook to the sources you chose (4.3), and used two of its specialist agents (4.4). All of that works on content Copilot already has a route to: your mail, files, chats, and whatever's indexed through Microsoft Graph. A connector is how more content, from outside Microsoft 365 entirely, joins that pool.
What a Copilot connector is
A connector brings content from an external system, ServiceNow, Salesforce, Box, Jira, MediaWiki, Azure, and well over a hundred others listed in the Connectors gallery, into Microsoft Graph. Once it's there, that content becomes searchable the same way your own files are: through Microsoft Search, through standard Copilot Chat, and through the specialist agents and tools built on top of Graph, including Researcher and Analyst from the last lesson, and as a knowledge source you can pick when building an agent in Agent Builder.
Picture what this actually unlocks. Before a connector exists for your ticketing system, asking Copilot "what's the status of the Henderson support case" gets you nothing, Copilot has no route to that data at all. After your admin deploys a connector for it, the same question can surface the ticket directly, because the content has joined the same pool Copilot already searches for your mail and files.
Where connected content actually shows up
It's not just the chat window. Once a connector is live and indexed, that content can surface in four separate places: a plain Microsoft Search query, a standard Copilot Chat answer, the scope Researcher draws on when you ask it to search "work content," and the list of knowledge sources you can tick when building an agent in Agent Builder. An agent you build for, say, answering questions against your company wiki only becomes possible once a connector has brought that wiki into Graph in the first place; Agent Builder can't reach a system Graph has never heard of.
Who actually sets one up
Here's the structural difference worth getting straight, because it changes how you should think about every connector you ever see show up in Copilot. With Claude, connecting an app is something you do yourself, in the moment: open the Connectors Directory, pick an app, click Connect, sign in, and it's live in your next chat.
A Copilot connector doesn't work that way. Setting one up requires the AI administrator role in the Microsoft 365 admin center: go to Copilot, then Connectors, choose a source from the Gallery, give it a name and URL, pick an authentication method, and create it. There's no equivalent flow where you, as an ordinary user, browse a directory and add any app you like. The closest thing is a newer middle ground: for some connectors (self-serve sync connectors and federated connectors), the admin enables the connector once and each user then signs in with their own account to start using it. Even then, what you can connect is limited to what your admins approved. Whatever external systems are reachable through Copilot are whatever your organisation has switched on, not whatever you personally decide to connect.
That's a real trade-off, not simply a restriction. A connector you set up yourself in Claude only ever affects your own chats. A connector an admin deploys in Copilot is a tenant-wide decision: once it's live, it's available to everyone the admin granted access to, which is exactly why standing it up needs someone with the authority to make that call for the whole organisation, not an individual flipping a switch for themselves.
Who can see what, once it's connected
This is the admin's second real decision, not an afterthought. For each connector, they choose between two access models: "only users with access to the content," which maps you by your email address to your identity in Microsoft Entra ID and surfaces indexed content only to people who could already see it in the source system, or "everyone in the organisation," which makes the indexed content visible tenant-wide regardless of who could open it at the source.
The first option is the one that matches how Claude connectors always behave: you only ever see what you could already see. The second has no real Claude equivalent at all, a connector can genuinely widen visibility beyond the source system's own access list if an admin chooses that setting, which is exactly why it's a deliberate admin decision and not a default anyone falls into by accident.
Keeping it tidy: the permission-sync catch
One operational detail worth knowing before you ever question a surprising search result: incremental crawls, the routine, frequent updates that keep a connector's content fresh, don't update permissions. If someone's access to a file changed in the source system, that change only propagates to Copilot's index on a full crawl, run periodically rather than continuously, not the moment the access change happens. If content ever looks like it's showing up for someone it shouldn't, or missing for someone it should reach, a stale permission sync is a real, documented explanation worth checking before assuming something's broken or escalating it as a security incident.
Act, not just read
Claude draws a clean line between a connector reading your data and one that can act, sending a message, creating a ticket, deleting a file, and asks you to treat the second kind with real caution. Copilot connectors started out mainly for search and retrieval, bringing content in to be found, but federated connectors, generally available since September 2026, are extending that same reach toward write, update, and delete actions, the same shift from "look things up" to "change things" that Claude's own connectors already make.
Picture the difference in practice. A read-capable connector lets Copilot answer "what's the current status of the Henderson ticket" by looking it up. A connector that also supports actions could let it answer "close the Henderson ticket and note that the fix shipped" by actually making that change in the source system. The first is a lookup with no consequences if it's wrong. The second edits a real record that other people rely on, which is exactly why the underlying judgement call matters here just as much as it does on Claude's side: looking something up is low-risk, changing something in the source system is not, and it deserves more scrutiny before you trust it to an agent running on its own.
Getting a connector you actually want
Since you can't add one yourself, the practical move when you want Copilot to reach a system it doesn't yet cover is to ask, not to look for a settings toggle that doesn't exist. Tell your IT or admin team specifically which system you need, what you'd actually ask Copilot once it's connected, and whether the content should realistically be visible to everyone or only to people who already have access in the source system. That last part matters more than it sounds: you're the person closest to knowing whether "everyone in the org" is the right call for that particular system, and handing the admin that judgement upfront, rather than leaving them to guess, is how you end up with a connector configured the way you actually need it.
Where this goes next
That closes out Part 4. You can manage the context Copilot builds for you automatically (4.1), package a repeatable job into an agent you can share (4.2), lock Copilot to exactly the documents a piece of work needs in a Notebook (4.3), reach for Researcher or Analyst when a question needs real depth (4.4), and now you know how outside systems join the mix and who controls that (4.5). Part 5 goes further still: the more specialised tools, scheduling and automation, and full playbooks that chain everything you've learned so far.
Try it
Think of one external system you use daily that isn't part of Microsoft 365, your ticketing tool, your CRM, a wiki. If Copilot could search it, what's the first real question you'd ask? Then ask yourself the admin's actual question: should everyone in your organisation be able to find that content through Copilot, or only the people who could already open it at the source? That's the exact decision your IT team has to make for every connector they deploy.