Roadmap ID 561326 describes a change to Copilot people connectors that would let organizations import people data from outside systems into Microsoft 365 along with access control lists (ACLs). That way, Copilot respects existing permissions defined in source systems. Microsoft also says the imported data can be scoped to specific individuals and groups, allowing Copilot to reason over people data while honoring access restrictions.
The wording is in the present tense, but this is not a shipping feature. The item's status is In development. It targets general availability in June 2027 on the Worldwide (Standard Multi-Tenant) cloud, and it is classed as a Developer platform feature.
The schedule has already slipped
This roadmap item is not new. It has just been updated. HandsOnTek's M365 Admin roadmap tracker recorded the original entry as Release date: August CY2026, created May 15, 2026. Merill Fernando's Message Center archive shows a second version posted November 11, 2026, and that version now lists the GA date as June CY2027.
So the target has moved back about ten months. The August 2026 date has passed with no release, and the item is still "In development."
Microsoft's own roadmap page warns that it gives estimated dates and that all information is subject to change. Admins who have been planning HR-data projects around this capability should treat June 2027 as a goal, not a commitment.
Summary: The feature is planned, it is not available, and its date has already moved once.
Why this matters: today's people connectors are all-or-nothing
To see why this roadmap item is a big deal, look at how people connectors work right now.
Microsoft's developer documentation says people connectors let you ingest people data and knowledge from your source systems, such as HR and talent-management platforms, into Microsoft Graph. From there it enriches profile cards, people search and Copilot answers. The same documentation states the current visibility model plainly:
- People data provided via a Copilot connector is visible to all users in the organization.
- Connector data is stored in the user's Microsoft 365 profile.
- You must set the access control list (ACL) on items ingested by the connector to grant access to everyone.
- Schema attributes such as isQueryable and isSearchable are ignored. All data about a person is indexed by default.
This was a deliberate design choice. When people connectors went into public preview, Microsoft's developer blog told builders to set an "allow everyone" ACL on each item, because profile data brought in via people connectors is organizational info by nature.
That reasoning works for job titles and skills. It does not work for an employee's home address, anniversaries or internal HR notes. The current schema supports all of those through labels such as personAddresses, personAnniversaries and personNote. Today, the only safe way to handle sensitive fields is to leave them out of the connector.
People data is catching up with other connectors
Permission trimming is not new to Copilot connectors in general. Microsoft's connector overview says each ingested item carries an access control list (ACL) that enforces permissions, and that Search and Copilot only show items to users who have access in the source system.
The Salesforce CRM connector is a good example. Its default setting, "Only people with access to this data source," enforces Salesforce record ownership, sharing rules, and role hierarchy. The Graph connectors API can also apply permissions based on external groups, which are non-Entra groups from source systems such as Salesforce or ServiceNow.
People data has been the exception. Roadmap item 561326 would bring it closer to the permission model other connector content already uses.
One caution: the roadmap entry does not say how this will work. It doesn't explain which ACL types will be supported for people items, whether external groups will be part of it, how scoped data will appear on profile cards, or whether existing people connections can be converted. It would be guesswork to assume the Salesforce-style model will carry over as is.
Who stands to benefit
If Microsoft delivers it as described, these groups will see the most practical impact:
- HR and people-analytics teams. They could bring in richer data, such as internal mobility notes or certification status, that should be visible to HR business partners and managers but not to the whole company.
- Developers building custom people connectors. The roadmap lists the feature under the Developer platform, so expect the work to fall on custom builds using the Graph external connections APIs first.
- Security and compliance teams. They have probably been rejecting sensitive fields during connector reviews because there was no way to restrict who sees them. Scoped visibility could reopen some of those discussions.
There is also a downside. Once Copilot can answer "who on the team has a PMP certification?" differently depending on who asks, troubleshooting gets harder. Two employees will get different answers about the same coworker, and help desks will need to understand why.
What admins can do now
Nothing in this item is available to configure yet. But the existing connector documentation points to some sensible prep work.
1. Audit your existing connector permissions. Microsoft's guidance is:
- In the Microsoft 365 Admin Center, go to Copilot > Connectors > Your Connections.
- Select the connector you want to review to open the details pane.
- Under Permissions, check whether the connection shows "Only people with access to this data source" or "Visible to everyone."
Microsoft warns that incorrect access permission settings, such as granting access to Everyone, can lead to oversharing of sensitive content. For the general connectors covered by that guidance, you cannot change permissions after a connection is created. The documented fix is to delete the connection and recreate it with Custom setup. Don't assume people connectors will get an easier migration path when ACL support arrives, because Microsoft hasn't said.
2. Review what your people connectors ingest today. Every field you map is visible to the whole tenant. If a field shouldn't be, remove it now rather than waiting until mid-2027.
3. Know the current technical limits. Microsoft's documentation lists several:
| Constraint | Current documented behavior |
|---|---|
| Content category | Must be set to people |
| Required label | One property labeled personAccount |
| Delay before data appears | Up to 6 hours after the connection is created |
| Staged connections | Not supported for people data |
| Accounts without Exchange Online mailbox | Ignored |
| Unsupported labels | personManager, personAssistants, personColleagues, personAlternateContacts, personEmergencyContacts |
The time it takes for data to appear has improved. During the preview, the developer blog estimated about 24-48 hours, while the current documentation says up to six hours.
4. Map your source-system permission model. If your HR platform uses role-based visibility, document how those roles correspond to Entra users and groups. When Microsoft publishes the implementation details, that mapping will be the work that takes the longest.
Our take: a necessary fix
This roadmap item fixes a real gap. People connectors were designed for org-chart data that everyone can see. But Microsoft has been promoting them as the way to make Copilot understand your workforce, and some workforce data shouldn't be shared with the whole company.
Adding per-item ACLs is the right fix. The concern is timing. The original August 2026 target is now June 2027. Until then, the only safeguard is careful field selection.
My advice: treat the people-connector schema like a public company directory, because in practice that's what it is right now. Copilot won't respect HR's need-to-know rules for people data until Microsoft ships this ACL support, and that release is not expected before mid-2027.