Microsoft 365 Copilot Connectors Best Practices - Lessons From Real Builds

The most common complaint I hear about Microsoft 365 Copilot from Australian businesses isn't that it's wrong. It's that it doesn't know anything about the systems that matter. It can summarise your inbox and find a Word doc in SharePoint, but ask it about a customer's open service tickets, the status of a project in your PSA tool, or a policy that lives in an old intranet, and it shrugs.

Copilot connectors (formerly Microsoft Graph connectors) are how you fix that. They ingest content from external systems into Microsoft Graph so Copilot and Microsoft Search can reason over it. Building one isn't difficult. Building one that Copilot actually uses well is a different matter, and Microsoft's best practices guidance for connectors is worth reading closely because the gap between a connector that works and a connector that is useful is almost entirely in the details it covers.

We've built a number of these now, for everything from job management systems to legacy document stores. Here's what I'd tell a developer starting their first one.

Treat the schema as a prompt, not a database table

The biggest mindset shift is this: your connector schema isn't just storage. Copilot reads it to understand what your content is. Property names, descriptions and labels all affect whether Copilot finds the right items and how it talks about them.

On our first connector build, we mirrored the source system's database columns more or less directly. Properties named things like stat_cd, cust_ref and dt_mod. Technically it worked. Copilot's answers were poor, because it had no idea what stat_cd = 4 meant.

The fix was boring and effective:

• Use plain, descriptive property names. ticketStatus, customerName, lastUpdated.
• Store human-readable values. "Awaiting customer response", not "4".
• Write property descriptions where the API allows, as if explaining the field to a new staff member.

Answer quality improved immediately, with no other changes.

Apply semantic labels properly

Semantic labels are well-known tags you assign to schema properties: title, url, createdBy, lastModifiedBy, authors, createdDateTime, lastModifiedDateTime, fileName, fileExtension, iconUrl and a few others. They tell Microsoft 365 how to interpret those properties, regardless of what you named them.

The guidance is clear that you should label everything that applies, and I agree completely. In particular:

• title is the single most important one. It's what shows up in results and citations, and Copilot weights it heavily. Make titles meaningful. "Ticket 48213" is bad. "Ticket 48213 - Pump failure at Gladstone site" is good.
• url needs to point to a working, user-accessible page for that item. Copilot cites it. If it 404s or goes to a login page with no deep link, users stop trusting citations quickly.
• lastModifiedDateTime helps Copilot favour fresh content. Without it, a three-year-old policy can outrank this year's version.
• createdBy / authors let Copilot answer "what did Sarah write about..." type questions and help with people-centric relevance.

Skip these and your content is still indexed, but it's second-class compared with native Microsoft 365 content.

Get the property flags right

Each schema property can be searchable, queryable, retrievable and refinable. It's tempting to switch them all on. Don't.

• Searchable means the full text is indexed for matching. Turn it on for properties that contain words people would search with, like titles, descriptions and tags. Not for IDs or dates.
• Queryable lets you filter on it. Good for status, category, region.
• Retrievable means the value can be returned in results and used by Copilot in its answer. If Copilot needs to mention a value, it must be retrievable.
• Refinable is for faceting in search experiences. Only some types support it and there are limits on combinations.

Marking everything searchable adds noise and can make relevance worse. Also, some of these settings are effectively locked once the schema is registered, so changing your mind means recreating the connection and re-ingesting everything. Spend an hour getting the schema right before you write any ingestion code. It's far cheaper than redoing it.

Content quality beats content volume

The content field of each external item is where the body text goes, and it is what Copilot grounds most of its answers on. A few things we've learnt:

Give it real text. If your source system stores rich content as HTML, either send it as HTML (which is supported) or strip it to clean text. Don't send raw markup with inline styles and tracking pixels. Don't send base64 blobs.

Include context in the content. A support ticket's content field should include the subject, the description, key comments and the resolution, written so a person could understand it without the source system open. One client's tickets had all the useful information in internal notes that we initially didn't ingest. Adding them made the difference between Copilot saying "this ticket exists" and Copilot explaining what the fix was.

Don't ingest junk. Test records, auto-generated notifications and empty drafts all compete with good content. Filter them out at the source. Copilot doesn't know your "TEST - do not use" records are fake.

Mind the size limits. Items have a maximum size. Very long documents may need to be split, and the split should happen at logical boundaries (sections, not every 4,000 characters).

Permissions are not optional

Every external item carries an ACL. The guidance recommends mapping the source system's real permissions rather than granting everyone access, and on this point I'd go further: if you can't map permissions accurately, think hard about whether that content should go into Copilot at all.

For systems that use Entra ID users and groups, mapping is straightforward. For systems with their own permission model (most line-of-business apps), external groups let you mirror those groups into Graph and keep membership in sync.

We had a project where the client initially wanted to grant "Everyone" access on a contracts repository "because it's internal anyway". Within a week of testing, Copilot surfaced a salary figure from an employment contract to someone in marketing. Nothing went outside the organisation, but it ended the "everyone" conversation pretty quickly. Map the permissions. If your security team is nervous about Copilot generally, our Copilot Studio consultants page talks about how we approach governance in these projects.

Make the connection itself descriptive

When you create the connection, you give it a name and description. These appear to admins and, more importantly, Copilot uses them to decide whether the connector is relevant to a question. "Connector 1" tells Copilot nothing. "ServiceDesk tickets - customer support cases, issues, resolutions and status for all field service customers since 2019" tells it a lot.

Set the content category too where it fits (things like knowledge base, wiki, file repository, ticketing, CRM, people). It helps Microsoft tune how results are treated.

Keep it fresh, but be sensible about crawls

Plan for both full and incremental crawls. Incremental crawls should pick up changes frequently enough that users don't get stale answers. For a ticketing system, every 15 to 30 minutes is usually fine. For a policy library, daily is plenty.

Handle deletions. A connector that never removes items will eventually have Copilot citing tickets and documents that no longer exist, which is a fast way to lose user trust.

Respect the throttling limits. We've seen ingestion jobs that hammered the Graph API on initial load, got throttled, and then didn't back off properly. Build in retry with exponential backoff from day one.

What's still rough

A few honest observations.

Testing is harder than it should be. There's no great way to ask "why did Copilot pick that item over this one?" You end up building a set of test questions, running them after each change, and comparing answers by hand. Tedious, but worth doing.

Schema changes are painful, as mentioned. Design carefully up front.

Visibility of usage is improving but still limited. You can see that a connector is ingesting fine, but understanding how often Copilot actually draws on it takes more work than it should.

And the naming keeps changing. Graph connectors, Copilot connectors, Microsoft 365 Copilot connectors. The concepts are stable even if the branding isn't.

Where to start

If you're thinking about a connector, pick one system where people regularly say "I wish Copilot knew about this". Usually it's the ticketing system, the CRM, or a knowledge base that predates SharePoint. Build that one properly, measure whether answers improve, then move on to the next.

We build Copilot connectors and broader Copilot extensions for Australian organisations through our Microsoft AI consulting and AI integration services. If you've got Copilot rolled out but it's not connected to the systems your people actually use, that's usually where the biggest jump in value is hiding.

Microsoft's original guidance: Best practices for Microsoft 365 Copilot connectors.