If we remove someone's access in ServiceNow, how long before Copilot stops showing it?

That’s the right question, and it’s one many organisations only ask after an incident. Copilot respects the permissions it has been told about. If what it’s been told is a day out of date, so is the protection.

Here’s what’s going on. Copilot connectors copy content and its access control lists (ACLs) into the Microsoft Graph index on two schedules. An incremental crawl picks up new and changed items, usually every 15 minutes (some connectors default to every four hours). A full crawl re-reads everything, removes deleted items and refreshes permissions, and its default is daily. Until now, permission changes mostly waited for the full crawl. So a leaver, or someone moved off a sensitive knowledge base, could still see that content in Copilot results for up to a day.

Roadmap 503570 is now Launched. It says permissions “were synced only in the periodic full crawl”, which defaults to once a day for most connectors, and that permission syncs can now happen “more frequently in an incremental way”. That’s a real improvement. But be careful about how far you lean on it, because the connector pages on Learn haven’t all caught up:

• The admin centre deployment guide still says “Incremental crawls don’t support permission updates. Run full crawls periodically.”
• ServiceNow Knowledge: incremental crawls recompute permissions for changed articles, but identity sync (users mapped to user criteria, group memberships) and knowledge-base-level permission changes still wait for the full crawl.
• Confluence On-premises and Azure DevOps Wiki: Learn says incremental crawls don’t pick up ACL or group changes, or deleted items.
• File share only supports full crawls.

So the honest answer is that it depends on the connector. Group membership changes, which is how most revocations actually happen, are the slowest to come through.

Schofield’s Third Law, that the easier something is for you to access, the easier it is for someone else, fits here. A connector makes old content easy to find for everyone the index thinks has access.

Options that actually work:

1. Measure your own window. Remove a test user from a group in ServiceNow or Confluence, then time how long it takes before Copilot stops citing that content. That number goes in your risk register.
2. Run full crawls more often for sensitive connections. The Sync tab lets you repeat crawls from every 15 minutes to every 12 hours. Check the source system’s API limits first.
3. Make leaver handling quicker than the crawl. Disabling the Entra account cuts off Copilot completely, whatever the index says, so do that before you tidy up access in the source system.
4. Keep the most sensitive spaces out of the index. A narrower connector scope, or a federated connector that queries live, avoids the delay altogether.

12 Panes action / comms: Tell Security: 503570 improves incremental permission sync, but group and identity changes still wait for full crawls on several connectors; here’s our measured window. Tell IAM: For leavers, disable the account first, then remove source access. Tell connector owners: Increase full-crawl frequency on sensitive connections and record the schedule. Leadership: Copilot follows source permissions, with a known and tested delay.

Benefits / risks: Faster permission sync narrows the gap for item-level changes, and the crawl schedule is something you can set. The risks are that the improvement varies by connector, the documentation is behind the roadmap, and group membership changes can still take up to a full crawl cycle to come through.

I’d suggest this week: list your connections, write down each one’s full-crawl schedule, and run one timed revocation test on the most sensitive one.

DIGITAL SKILL WORKS LTD / 12 PANES · You ask, we answer