Making Microsoft 365 Copilot Answer From Your Own Data With Graph Connectors

Most Australian organisations that switch on Microsoft 365 Copilot get a nasty surprise in the first fortnight. Copilot is genuinely good at reasoning over the emails, documents and Teams chats sitting in Microsoft 365. Ask it about anything that lives outside that boundary though, your CRM notes, your ticketing system, the knowledge base in Confluence, the policy documents in a legacy SharePoint nobody migrated, and it draws a blank. Or worse, it makes something up that sounds plausible.

That gap is the whole reason the Graph connectors API exists. It is the mechanism for pulling external content into the Microsoft Graph so Copilot can actually find it, cite it, and reason over it alongside the native Microsoft 365 stuff. I have set enough of these up on client work to have firm opinions about where it shines and where it will waste a week of your time if you go in blind. Microsoft's connectors API overview is the reference. This is the field guide.

What a Graph connector actually does

Strip away the marketing and a Graph connector does one job: it copies your external content into a search index that lives inside Microsoft Graph, keeps it up to date, and attaches enough metadata and permissions that Copilot and Microsoft Search can use it safely.

The content stays where it is. You are not migrating your CRM into SharePoint. What you are doing is indexing it, creating a searchable, permission-aware shadow of that content inside the Microsoft 365 boundary so Copilot can retrieve the right bits when someone asks a question. When a sales rep asks Copilot "what did we agree with the client on renewal pricing", a connector that has indexed your CRM notes means Copilot can answer from the actual record instead of guessing.

There are two ways in. You either use one of Microsoft's pre-built connectors, and there is a decent library of them now for the common systems, or you build a custom one against the connectors API when your source is bespoke or not covered. The pre-built ones are a click-and-configure job in the admin centre. The custom ones are real development work, and that distinction matters more than the docs let on.

The four moving parts

Every connector, custom or not, is built from the same handful of pieces, and understanding them saves a lot of confusion later.

A connection is the container. It represents one source of content, your ServiceNow instance, say, and everything else hangs off it. A schema defines the shape of each item you are indexing: which properties exist, and critically, which ones are searchable, queryable, retrievable, and refinable. That schema is the single most important decision you make, and I will come back to why. Then you push the actual content in as items, each one carrying its properties, its content, and its access control list. Finally, ongoing crawls keep the index fresh, either a full recrawl or an incremental one that only picks up what changed.

The bit people underestimate is the access control list on every item. Copilot respects source permissions, which is exactly what you want. If a user cannot see a document in the source system, Copilot must not surface it to them either. But that means you have to map your source system's permissions onto the ACLs you push with each item, and if you get that mapping wrong you have either broken search, where nobody sees anything, or a data leak, where people see things they should not. On a Copilot rollout the second one is the career-limiting outcome, so this is the part to get right before anything ships.

Where connectors genuinely earn their keep

When it works, it is quietly brilliant. The value is not in any single query, it is in Copilot stopping being an island.

We had a professional services client whose consultants kept re-answering the same client questions because the institutional knowledge was scattered across an old wiki, a shared drive, and a project system none of them wanted to open. Once that content was indexed and Copilot could cite it, the questions started getting answered in seconds with a link back to the source. Nothing about the underlying systems changed. The content just became findable through the tool people already had open.

The citation behaviour is the underrated part. Copilot does not just answer from connected content, it links back to the source item. That single feature does more for user trust than anything else, because people can click through and verify. An answer with a source is something a compliance officer will accept. An unsourced answer from a black box is something they will ban.

This is also where a connector beats bolting a chatbot onto each individual system. You index once into Graph and every Copilot surface, Teams, Word, the Microsoft 365 app, gets the content for free. If you are weighing that architecture up, it is the kind of decision our Microsoft AI consultants spend a lot of time on with clients, because getting the platform choice right up front saves rebuilding it in eighteen months.

Where it will frustrate you

I like Graph connectors and I will still tell you honestly where they bite.

The schema is effectively permanent, so plan it properly. Deciding after go-live that a property really should have been queryable or refinable means reworking the connection, and that is not a two-minute change. Spend real time on the schema before you index a single item. Work out which properties people will actually filter and search on, because retrofitting is painful.

Permissions mapping is the hard part, every time. Source systems model access in wildly different ways, groups, roles, record-level rules, and flattening all of that into the ACL format the Graph expects is where custom connector projects overrun. If your source has complex or dynamic permissions, budget serious time for this and test it with real user accounts, not just an admin who can see everything.

Freshness is a design decision, not a default. Incremental crawls keep content current, but you have to build the change-tracking to support them, and if your source has no reliable "what changed since" signal you are stuck doing expensive full recrawls. For fast-moving content that gets old and awkward.

And custom connectors are proper software. They need hosting, monitoring, error handling, and someone to own them when a crawl silently stops at 2am. Treat one as a small production service, because that is what it is. This is the same operational reality behind any of the ongoing platform work our AI managed services cover: the build is the easy part, keeping it healthy is the job.

How we approach a connector build

The order we work in has been earned through a couple of projects that taught us the hard way. Content and permissions first, connector second. Before writing any code we map exactly what content is worth indexing, because indexing everything is a common and expensive mistake. Half the content in most source systems is stale, duplicated, or nobody should be searching it anyway. Indexing it just makes Copilot's answers worse and your bill higher.

Then we model the permissions properly, on paper, before touching the ACL code, because that is the part that carries real risk. Only once we know what we are indexing and who is allowed to see it do we design the schema, and only then do we build. The connector itself is usually the least difficult part of the whole exercise. Deciding what belongs in the index, and enforcing who can see it, is where the actual work sits.

If Copilot has landed in your organisation and everyone is underwhelmed because it cannot see the systems where your real knowledge lives, a well-scoped connector is often the thing that turns it from a novelty into something people rely on. That kind of Copilot enablement is squarely what our business AI team does day to day.

The short version

Graph connectors are how you make Microsoft 365 Copilot answer from your own content instead of just the files already sitting in Microsoft 365. They index external content into the Graph with a schema, per-item permissions, and ongoing crawls to stay fresh, and Copilot cites its sources back to the original system, which is the feature that earns user trust. The build is not the hard part. Choosing what to index, designing a schema you can live with long term, and mapping source permissions accurately onto item ACLs are where projects succeed or quietly leak data.

If you are rolling out Copilot and want it to actually see the systems your business runs on, that is the work we do. Have a look at our services or get in touch and tell us where your knowledge is hiding.