2.1.1. Copilot Connectors
💡 First Principle: Copilot connectors solve grounding by ingestion: instead of teaching the agent to search an external system, they copy that system's content into the Microsoft 365 semantic index — the same index that powers Microsoft 365 Copilot — so one retrieval surface can answer from everything.
Copilot connectors are the current name for what were Graph connectors, and the rename tells you their purpose: they exist to feed Copilot experiences. A connector crawls an external source — a third-party wiki, a ticketing system, a network file share — and pushes its items into the Graph as external items with searchable text, metadata, and access control lists. Once ingested, that content behaves like native M365 content: it appears in search, respects mapped permissions, and becomes available to Copilot Studio agents as knowledge.
The architecture explains both strengths and limits. Because content is ingested ahead of time, query latency is excellent and retrieval quality benefits from Microsoft's semantic index — but freshness depends on crawl schedules, and the approach fits unstructured content far better than transactional records. Because items carry ACLs from the source system, answers honor the asking user's permissions — a governance property the exam rewards you for noticing.
⚠️ Common Misconception: Copilot connectors and Power Platform connectors are the same thing. They share a word, not a job: Copilot connectors ingest content into the M365 semantic index for retrieval; Power Platform connectors wrap APIs for live queries and actions. When a scenario says "make external content searchable alongside SharePoint," it is describing ingestion — Copilot connectors.
Reflection Question: Your engineering wiki lives outside Microsoft 365, and users want its pages cited in agent answers next to SharePoint documents. Why is ingestion the right verb here — and what stays wrong if you wrap the wiki's API as a Power Platform connector instead?
