Using External Groups to Control Who Sees What in Copilot Connectors

Every time we build a Microsoft 365 Copilot connector for a client, the same question comes up about halfway through, usually from someone in security who has just realised what is being switched on. "So when Copilot searches this content, who is allowed to see it?" Fair question. It is the question that decides whether the connector ships or sits in a review queue for three months.

For a lot of content the answer is easy. You attach permissions to each item using the identities Microsoft already knows about, the users and Entra ID (formerly Azure AD) groups in your tenant, and Copilot respects them. Someone searches, Copilot only returns what that person is allowed to see, everyone is happy. That works right up until you connect a system whose permissions do not map cleanly onto anything in Entra ID. A legacy case management tool with its own concept of teams. A project system where access is governed by "membership of the Northern region delivery pod", a group that exists nowhere in your directory. That is where external groups come in, and it is one of the more misunderstood parts of the connector model.

The Microsoft documentation on using external groups explains the API surface. What I want to add is the judgement around it: when you actually need external groups, when you are better off without them, and where they quietly break.

What an external group actually is

Start with the problem it solves. When you ingest content through a Copilot connector, each item needs access control information so Copilot knows who can see it. The clean case is when access is defined by identities that live in your tenant. You grant an item to a user by their Entra ID identity, or to a group by its Entra ID group ID, and you are done. Copilot already understands those identities, so it can evaluate them at query time without any extra help from you.

But plenty of source systems do not describe access that way. They have their own groups. A ticketing system might say "this ticket is visible to the Payments Support squad", where "Payments Support squad" is a construct that only exists inside the ticketing system. There is no matching group in Entra ID, and you do not want to create and sync one just for this. An external group lets you define that grouping inside the connector itself. You tell the connector "here is a group called payments-support-squad, and here are its members", and then you can grant items to that external group by ID, exactly as you would an Entra ID group.

The members of an external group can be Entra ID users, Entra ID groups, or even other external groups. That nesting matters more than it first appears, and I will come back to it. The point is that external groups let your connector mirror the source system's own access model faithfully, without forcing that model into the shape of your corporate directory.

When you genuinely need them, and when you do not

My honest position is that external groups are a tool you should reach for only when the simpler option is genuinely unavailable, because they add a moving part you now own forever.

You do not need external groups when the source system's permissions already correspond to Entra ID groups. If access to a SharePoint-adjacent content store is governed by the same security groups you use everywhere else, just grant items to those Entra ID groups directly. Do not build a parallel group structure inside the connector that duplicates what the directory already holds. That is a maintenance burden you are volunteering for, and it will drift out of sync the first time someone updates the directory group and forgets the connector exists.

You do need external groups when the source system's access model has no counterpart in Entra ID and you cannot reasonably create one. The classic case is a line-of-business application with its own permissions engine: bespoke teams, project-based access, region or client groupings that were never modelled as directory groups because they never needed to be. Rebuilding all of that as Entra ID groups just to satisfy the connector is usually the wrong trade. It clutters your directory with connector-specific groups, and it means two systems of record for the same access decision. External groups keep that logic where it belongs, inside the connector, mirroring the source.

Getting this call right early is a big part of what our Copilot Studio consultants do on these engagements, because it is one of those decisions that is cheap to make well up front and expensive to unwind once you have a hundred thousand items granted the wrong way.

Keeping the membership honest

Here is the part that catches teams out. An external group is only as good as its membership data, and that membership is a snapshot you are responsible for keeping current. Entra ID groups update themselves as people join and leave. External groups do not. When someone moves off the Payments Support squad in the source system, nothing happens in your connector until you tell it. Until you do, that person keeps seeing content in Copilot they should no longer see.

That is a real access control failure, and it is the kind that does not announce itself. Nobody files a ticket saying "I can see too much". So the refresh strategy for external group membership is not an afterthought, it is central. Whatever process syncs your content also has to sync your group memberships, and it has to handle removals as carefully as additions. Adding a new member is the easy, visible case. Removing someone who left a team is the case that actually protects you, and it is the one people forget to build and test.

We treat the membership sync as a first-class part of the pipeline, on the same schedule and with the same monitoring as content ingestion. If the source system can tell you what changed rather than making you re-read everything, use that, because full membership rebuilds on a large system get expensive and slow. But whatever you do, do not let membership go stale while content stays fresh. A connector where the documents are current and the permissions are three weeks old is worse than one that is uniformly out of date, because it looks trustworthy while quietly being wrong.

Nesting, and the debugging headache it brings

Because external groups can contain other external groups, you can model quite rich hierarchies. A regional group that contains several squad groups, each containing users. That expressiveness is genuinely useful for mirroring a source system that works the same way. It is also where the hardest bugs live.

When access is not resolving the way you expect, and someone can see something they should not or cannot see something they should, you are now tracing membership through layers. Is the user directly in the group? In a nested external group inside it? In an Entra ID group that is a member of the external group? Every layer is a place the resolution can go wrong, and every layer is a place your sync process can have missed an update. My advice is to keep the nesting as flat as the source model honestly allows. Do not build hierarchy for elegance. Build only the structure you actually need to represent the real access rules, because every level you add is a level you will eventually have to debug at 4pm on a Friday while someone from compliance watches over your shoulder.

When we design these, we push for the shallowest structure that faithfully represents the source. It is less clever and far easier to reason about, and reasoning about access control is the whole job here. This kind of careful permissions modelling sits inside our broader Microsoft AI consulting work, because the connector plumbing is only ever as good as the access decisions underneath it.

A few field notes

Test with real edge-case users, not just yourself. The person who is in three squads, the contractor who is in one, the manager who has visibility across a region. Those are the accounts where nested membership and mixed identity types expose the bugs. Your own admin account can usually see everything, which makes it the worst possible test case.

Watch the identity matching between external group members and real tenant users. If the identifier you use to add a user to an external group does not cleanly resolve to that user's Entra ID identity, the grant silently does nothing, or attaches to the wrong person. This is the same class of subtle bug that bites people connectors, and it is worth deliberately hunting for with contractors, renamed accounts, and shared mailboxes.

And treat external group changes as security events, because that is what they are. When membership shifts, someone's access to content in Copilot shifts with it. Log it, monitor it, and be able to answer "who was in this group on this date" if you are ever asked. In a lot of Australian organisations, especially anything touching regulated data, being able to reconstruct who could see what is not optional.

The bottom line

External groups are the right answer to a specific problem: a source system whose access model does not fit your directory and should not be forced to. Used for that, they let a connector honour the source's real permissions instead of a lossy approximation. Used for anything Entra ID could already handle, they are just extra machinery you now have to keep in sync forever. Reach for them deliberately, keep the membership as current as the content, keep the nesting shallow, and test with the awkward accounts. Do that and Copilot returns the right things to the right people, which is the entire point of getting permissions right in the first place.

If you are planning a Copilot connector and the permissions story is what is keeping it in review, that is exactly the kind of problem we like. Take a look at our AI agent builders work, or get in touch and tell us what you are trying to connect.

Reference: Use external groups