Managing the Schema for a Microsoft 365 Copilot Connector - The Part That Decides Whether Search Actually Works
If you want Microsoft 365 Copilot to answer questions using your own business data, not just your emails and documents but the stuff sitting in your CRM, your project system, your internal wiki, or that line-of-business app someone built in 2016, you use a Microsoft Graph connector. The connector pulls that external content into the Microsoft 365 semantic index so Copilot and Microsoft Search can find it and reason over it. And the single most important decision you make when building one is the schema.
I have seen teams spend weeks on the ingestion pipeline, the authentication, the sync scheduling, all the plumbing, and then treat the schema as an afterthought they can fix later. That is backwards. The schema is the thing that determines whether your content is findable, whether Copilot can actually use it, and whether search results are any good. Microsoft's documentation on managing the schema for a Graph connector lays out the mechanics. This post is about what those choices actually mean in practice, because the docs tell you what the flags are but not which ones matter and why.
What the schema actually is
The schema is where you tell Microsoft Graph what your data looks like and, more importantly, how it should be treated. For each property in your content, you declare its type and then set a small number of behaviour flags. Those flags are the whole game. Get them right and search feels like it just knows what you meant. Get them wrong and users type a perfectly reasonable query and get nothing back, then conclude the connector is broken and stop using it.
There are three attributes that do most of the work, and it is worth being genuinely clear on each because they are easy to mix up and painful to change later.
Searchable means the content of the property is included in full-text search. If someone types words that appear in this property, the item can match. Your title fields, description fields, body content, anything with words a person might search for, these need to be searchable. This is the one people usually get right because it is obvious.
Queryable means you can filter and target the property in a structured query, using its exact value rather than free text. Think of a status field where you want to match "Active" precisely, or a category, or a date range. Queryable is what lets you say "show me items where region equals Queensland" rather than just hoping the word Queensland appears somewhere.
Retrievable means the property comes back in the search results so it can actually be displayed. A property can be searchable but not retrievable, which means it helps a query match but you never see its value in the result. That sounds odd until you use it deliberately, for example indexing a big body of text for matching but only showing a short title and summary in the results.
There is also refinable, which lets a property be used as a filter facet, the kind of "narrow by type, narrow by author" sidebar you see in a good search experience. You do not always need it, but when you do, you need to have set it up front.
The flag most people set wrong
Here is the trap. Each of these attributes has to be decided per property, and some of them cannot be changed after the fact without re-indexing your entire content set. Retrievable and refinable in particular are decisions you want to get right the first time, because discovering three months in that a field you need to display was never marked retrievable means a full re-crawl, which on a large content source is not a quick job.
The mistake I see most is teams marking almost nothing as queryable because they are thinking about search like a search box, where you type words and get results. But Copilot is not just a search box. When Copilot reasons over your content, structured filtering matters enormously. If you have a support ticket connector and the "status" field is not queryable, Copilot cannot cleanly answer "how many open tickets are there for this customer", because it cannot filter on status as a value. It can only match the word "open" wherever it happens to appear, which is fuzzy and unreliable. So think about the questions people will actually ask Copilot, then work backwards to which properties need to be queryable to answer them.
The opposite mistake is marking everything as everything, on the theory that more is safer. It is not. A bloated schema makes your index larger, your crawls slower, and your results noisier, because now internal ID fields and timestamps are competing with real content for relevance. Be deliberate. Every property should have a reason for each flag it carries.
Labels are how Copilot understands meaning
Beyond the true and false flags, Graph connectors let you assign semantic labels to properties. This is where you tell the system that a particular property is the title, or the URL, or the author, or the created date, or the last modified date. These labels are not decoration. They are how Microsoft 365 maps your arbitrary field names onto concepts it already understands.
If your data has a field called "docOwner" and you label it as the author, Copilot now knows that field answers "who wrote this". Without the label, "docOwner" is just a string of characters with no meaning attached. Labelling your title, URL, and date fields properly is one of the highest-value things you can do, and it is quick. It directly improves how results are displayed and how well Copilot can reason about recency and ownership. Skipping it is leaving obvious value on the table.
This is exactly the kind of detail that separates a connector that demos well from one that actually earns its keep in daily use, and it is a big part of what our Copilot extensibility work focuses on when we build these for clients.
The bits the docs undersell
A few hard-won lessons from actually shipping these.
Start with a smaller schema than you think you need, but design it so it can grow. You can add properties to a schema later, so resist the urge to model every conceivable field on day one. Get the core content flowing, see how people search it, and add properties in response to real queries rather than imagined ones. This keeps your first version simple and lets the real usage tell you what is missing.
Test with real queries early, and test them as a normal user, not as the person who built the schema. You know the field names. Your users do not. They will type things you did not anticipate, and the gap between what they type and what your schema can match is where the connector lives or dies. We usually sit with a few actual end users and watch them search, because that half hour surfaces more problems than a week of theorising.
Think about permissions alongside the schema, not after it. Content coming in through a connector needs its access controls mapped so that Copilot only surfaces items a given user is allowed to see. This is not strictly a schema property, but it is part of the same design conversation, and getting it wrong means Copilot cheerfully surfaces a document someone was never meant to read. That is the kind of mistake that ends up in an incident report, so treat it as a first-class concern from the start.
Where this fits in the bigger picture
Graph connectors and their schemas are one of the genuinely powerful parts of the Copilot extensibility story, because they are how you get Copilot to know about your business, not just about Microsoft's built-in data. When it works, an employee can ask Copilot a question and get an answer drawn from the CRM and the internal wiki and the project system all at once, without knowing or caring which system the answer came from. That is a real shift in how people get information.
But it only works if the schema underneath is thought through. The schema is where you encode what your data means, and Copilot is only ever as smart as the meaning you gave it. This is the same theme that runs through most serious AI for business operations work: the impressive AI layer sits on top of unglamorous data modelling, and the modelling is where the value is actually made or lost.
If you are planning a Copilot rollout and want your own business systems to be part of it rather than sitting off to the side, that is work we do regularly, and we are happy to help you scope it. Get in touch and we will talk through what your connectors and schemas need to look like to actually deliver.
Reference: Manage the schema in the Microsoft 365 admin center or Graph connector, Microsoft Learn.