Building Microsoft 365 Copilot Connectors for People Data - What Actually Works

Ask a Microsoft 365 Copilot user what they most want it to know, and after documents and email, the answer is almost always people. Who works on what. Who to ask about the Perth contract. Who owns the incident that just blew up. Copilot is decent at the content in your tenant out of the box, but the moment you want it to reason about people and their relationships to work, you are usually looking at a connector that brings people data in from somewhere else: an HR system, a project tool, a CRM, a bespoke internal directory.

This is one of the more useful things you can do with Copilot extensibility, and one of the easier ones to get subtly wrong. People data is sensitive by nature, the permissions model is unforgiving if you are sloppy, and the difference between a connector that delights users and one that gets switched off by security is mostly in decisions you make early. I have built and reviewed enough of these now to have opinions, so here they are.

Why people connectors are different

Most Copilot connectors ingest documents or records. You map some fields, set some permissions, and Copilot can search and cite the content. People connectors are the same plumbing with a sharper edge, because the data describes humans and their roles, and because Microsoft treats certain people signals specially.

When you bring people data in through a Microsoft 365 Copilot connector, you are not just making it searchable. Done right, you are enriching the profile Copilot already has of a person from Entra ID and the Microsoft Graph, adding the things Microsoft does not know: that Sarah is the subject-matter expert for the mortgage origination platform, that Tom sits across three project teams, that the on-call roster for the payments service rotates weekly. That enrichment is what makes Copilot able to answer "who should I talk to about X" instead of just returning documents that mention X.

The Microsoft guidance on building connectors with people data covers the mechanics of schema and semantic labels. What I want to add is the judgement: what to bring in, how to keep it safe, and where these things fall down in a real Australian organisation.

Semantic labels are the whole game

The single most important part of a people connector is the semantic labelling of your fields. Copilot connectors let you tag a field with what it means, not just what it is called. A field is not just "userPrincipalName", it is the semantic label that says "this is the person this record is about". A field is not just "expertise_tag", it is labelled so Copilot understands it describes what someone knows.

Get this right and Copilot can actually reason. It can connect a record in your connector to the real person in the tenant, surface them in responses, and respect the permissions attached to that person. Get it wrong, leave fields unlabelled or mislabelled, and you have imported a pile of text that Copilot can search but cannot understand as being about people. The connector technically works and delivers almost none of the value.

My honest take is that teams rush this step because it feels like metadata bookkeeping, and it is the step that determines whether the whole thing was worth building. Spend the time. Map every field that identifies a person to the correct identity label, and be precise about which field is the anchor that ties your record back to a real user in Entra ID. If that link is fuzzy, everything downstream is fuzzy. This mapping work is a big part of what our Copilot Studio consultants do on these projects, because the schema decisions are the ones that are expensive to unwind later.

Permissions: assume the strictest thing until proven otherwise

Here is where people connectors earn their reputation. Copilot respects the permissions on the data it retrieves, which means your connector has to tell Copilot who is allowed to see each record. If you get that wrong, Copilot will happily surface a person's data to someone who should not see it, and it will do so confidently, in a nicely formatted response, which is worse than a database leak because it looks authoritative.

The mistake I see most is defaulting to "everyone in the organisation" because it is easy and the demo works. For a directory of who-knows-what, broad visibility might be genuinely fine and even desirable. For anything touching HR data, remuneration, performance, or personal circumstances, broad visibility is a serious problem, and in Australia it can put you sideways of the Privacy Act and your own internal obligations fast.

So my rule is to start locked down and open up deliberately. Model the permissions on each record to match the source system's own access rules, not a convenient approximation of them. If the HR platform restricts a field to a person's manager and HR, the connector must carry that restriction through, per record, using access control lists tied to the right groups or users. This is more work than a blanket permission and it is the work that keeps the connector alive after the security review. A people connector that leaks is not a bug you patch. It is a connector that gets pulled and a project that loses trust.

Decide what people data actually helps, and leave the rest out

There is a temptation, once you have built the pipe, to pour everything through it. Full HR records, org history, the lot. Resist it. The best people connectors I have worked on are narrow. They bring in the handful of things that make Copilot more useful for actual work and deliberately exclude the rest.

For most organisations the high-value people signals are expertise and responsibility. What is this person the go-to for. What do they own. What teams or systems or clients are they connected to. That is what turns "find me a document about the claims engine" into "Priya rebuilt the claims engine last year, here is her and the design doc". Salary, performance ratings, personal details, none of that makes Copilot better at helping someone do their job, and all of it multiplies your risk. Leaving it out is not just safer, it is a better product.

I would rather ship a connector that knows five useful things about each person, with airtight permissions, than one that knows fifty and needs a lawyer to sign off. Scope is a feature. This kind of "what is actually worth connecting" call is exactly the conversation we have early in engagements, and it sits inside our broader Microsoft AI consulting work, because the answer depends on how your people actually work, not on what your systems happen to store.

Keeping it fresh without hammering the source

People data changes. Someone moves teams, picks up a new system, leaves. A people connector that reflects last quarter's org chart is not just stale, it is actively misleading, because Copilot will confidently point you at the person who used to own something. So the refresh strategy matters more than for a document connector, where a slightly old file is usually harmless.

The practical tension is between freshness and load. You want the connector current, but you do not want to re-ingest the entire HR system every hour and hammer a source that was never built for it. Incremental sync, where you only pull what changed, is the answer, and it is worth the extra engineering. Full crawls are fine on a schedule for a baseline, but the day-to-day should be deltas. Watch out for deletions especially: when someone leaves or a record is removed at the source, the connector has to remove it too, or you have a ghost in Copilot pointing people at someone who is gone. Deletions are the thing teams forget to handle and the thing that quietly corrupts trust in the connector.

What to watch out for

A few field notes.

Identity matching is where the subtle bugs live. If the field you use to tie a record back to a real user does not cleanly match the person's identity in the tenant, Copilot either fails to connect them or, worse, connects them to the wrong person. Test this hard with real edge cases: contractors, people with name changes, shared or role-based accounts. These are exactly the records that break naive matching.

Do not confuse "Copilot can find it" with "Copilot understands it". Search working is not the same as the semantic labels being right. Test by asking Copilot people-shaped questions and seeing whether it reasons about the person, not just quotes the record.

And bring security and privacy in at the start, not at the review gate. A people connector is a privacy decision wearing an engineering hat. The organisations that build these well treat the privacy conversation as design input, not a hurdle at the end, and they ship connectors that survive scrutiny because scrutiny shaped them.

The bottom line

People connectors are one of the highest-value and highest-risk things you can build with Copilot extensibility. The value comes from semantic labels done properly, so Copilot reasons about people rather than just searching text. The safety comes from carrying real per-record permissions through faithfully and being ruthless about which people data is actually worth including. Narrow scope, tight permissions, honest freshness, and careful identity matching. Do those and you get an assistant that genuinely helps people find people, which is one of the things Copilot should be best at.

If you are looking at bringing people or systems data into Copilot and want it built so it helps without leaking, that is squarely what we do. Take a look at our AI agent builders, or get in touch and tell us what you want Copilot to know.

Reference: Build connectors for people data