Connect to Copilot connectors

A support agent answers "what is our split-tunnel VPN policy?" from a Confluence article, and cites the article. Nothing in Copilot Studio touched Confluence when the user asked. The article had been copied into Microsoft Graph weeks earlier by a connector a tenant administrator configured, and the agent searched that copy. Read that sentence twice, because almost every design rule, failure mode, and exam distractor on this page falls out of it.

Microsoft states the mechanism plainly: Copilot connectors index your organization's external data into Microsoft Graph. This configuration enables the data to be added as a knowledge source for any agent in Copilot Studio^[1]. The comparison article gives it a name worth carrying: index-then-answer^[2]. An admin sets up a connection and data is indexed into Microsoft Graph; later, the agent issues a semantic query, Microsoft Graph returns items, and the language model grounds an answer and cites its sources. The figure below sets that path against the alternative this domain's next page owns.

These connectors are the same feature that used to be called Microsoft Graph connectors, and Microsoft's own comparison article carries the rename in parentheses (Copilot connectors, formerly Microsoft Graph connectors^[2]). Older material, and some current UI text, still says Graph connector. This guide says Copilot connector everywhere after this paragraph.

Which slice of the domain this page owns

This domain has two connector pages and they divide by what the connector does with the data. Copilot connectors, the indexed knowledge side, are this page. Power Platform connectors, the live-call side used as real-time knowledge or as a tool that reads and writes, belong to Connect to Power Platform connectors. Microsoft publishes one article that straddles the seam. The comparison table above borrows that article's dimensions and splits its single Power Platform column into the two uses this exam distinguishes, live knowledge and tools, so it is this guide's arrangement of Microsoft's own axes rather than a reproduction of the published table. Wherever this page compares the two mechanisms, it is orienting you toward that sibling rather than teaching it.

One level up, the knowledge surface as a whole (the Add knowledge dialog, the full catalog of source types, SharePoint, and how the orchestrator picks among sources) is Configure custom knowledge. Deciding whether an enterprise system belongs in an agent at all is Plan enterprise integrations. This page starts once that decision has landed on "index it".

A word that already means something else

In the Add knowledge dialog you select the desired connection and then select Add to agent^[1]. That word does not mean here what it means on the Power Platform pages. A connection in the Power Platform sense is a stored authentication credential for a connector. The thing you pick here is a Microsoft Graph connection: the indexed data set an administrator created, with its own schema and its own crawled content. Two objects, one word, and the mental model matters: the credential half of a Copilot connector is the administrator's to create, never yours. This page writes Graph connection when it means the indexed data set.

The four settings, applied to this source type

This guide describes every knowledge source with the same four questions, and it is worth landing them on this source type immediately. Retrieval scope is the set of Graph connections you selected. Content path is ingested rather than live: a synced connector (the type this page means throughout, set against its federated sibling in the next section) copies the content and semantically indexes it into Microsoft Graph, and the agent reads the index. Identity is the agent user's Microsoft Entra ID authentication^[3], enforced against access control lists that were indexed alongside each item. Selection metadata is the name and description generative orchestration reads when it decides this source is relevant. Two names for one split are worth pinning down before they drift apart. Ingested source against live source is this guide's shorthand for the value of one setting, content path, and it is not a Microsoft label. Indexed path against live path is how this page names the two whole routes a request can take, and it is the wording every figure uses. An indexed path is the one whose knowledge sources are ingested sources.

Synced and federated: one family, two behaviors

One bound belongs at the top rather than buried later. Microsoft publishes two types of Copilot connector: synced connectors, which index data into Microsoft Graph for Copilot and search, and federated connectors, which use a Model Context Protocol model to fetch data in real time without indexing content into Microsoft 365^[4]. The differences are structural: synced connectors are organization-level and admin-configured and support custom connectors; federated connectors are admin-enabled with users authenticating, are read-only, and have no custom option. Copilot Studio's own guidance describes the indexing behavior, which is the synced type, and that is what this page means whenever it says a Copilot connector indexes. If a design depends on the federated variant, confirm its behavior on the Microsoft 365 side rather than assuming the indexed rules carry over.

The order the rest of the page runs in

Setup first, because the tenant half and the agent half are genuinely different jobs. Then what an indexed item actually carries, then the schema work that decides how well it answers, then the permission model that rides on it. Then the two agent settings this page keeps coming back to: tenant graph grounding, which is the Generative AI setting that turns semantic search on for this content and gets a section of its own, and the agent's authentication option. Then the choice between indexed and live, running both in one agent, and reading a connector that works everywhere except in your agent.

Standing up a Copilot connector knowledge source is two jobs in two products: tenant-administrator setup in the Microsoft 365 admin center, then maker setup in Copilot Studio, and nothing in the second half can substitute for the first. Microsoft's own setup checklist splits exactly there: in the Microsoft 365 admin center, choose a prebuilt or custom connector, configure schema, apply semantic labels, and complete indexing; in Copilot Studio, add knowledge and select the enterprise connection^[2]. The figure below lays the eight steps out in order and marks where the handover happens.

The first four steps are administrator work, and this page treats them as a dependency rather than a procedure. What matters to you as the builder is that they must already be done, that you cannot do them from Copilot Studio, and that the schema work among them, semantic labels included, is what sets how well your agent's answers land, because Microsoft's own warning is that incorrectly mapping labels degrades the search experience. The section on reading a misbehaving connector comes back to that.

The agent half, step by step

Microsoft documents the maker path as four moves:

1. Open the agent.
2. Select Add knowledge from either the Overview or Knowledge pages, or the Properties of a generative answers node^[1], the topic node that produces a grounded answer by searching knowledge sources. All three entry points reach the same dialog; which one you use decides only the scope of the source, agent-wide or node-only, which is Configure custom knowledge territory.
3. From the Add knowledge dialog, select the Copilot connector you want. Microsoft attaches a note here that is worth memorising because it is the first branch of every troubleshooting path on this page: if you do not see the Copilot connector you are searching for, select Advanced; if the connector still does not appear, contact your admin^[1].
4. Select the desired Graph connection and then select Add to agent.

That is the whole authoring act. There is no crawl to schedule, no schema to map, and no index to build from inside Copilot Studio, because all of it happened on the tenant side first.

What is available to select

The catalog is not a Copilot Studio catalog: what you can select is the set of Copilot connectors a tenant administrator has already configured on the Microsoft 365 side. Copilot Studio supports all of the Copilot connectors listed under the Microsoft 365 Copilot connectors overview for Microsoft Search^[1] article, and Microsoft offers over 100 prebuilt connectors for popular services, including Box, Dropbox, Google Drive, Confluence, MediaWiki, network file shares, Salesforce, ServiceNow, Dynamics 365, Azure services, SQL and Oracle databases, SAP, Workday, Zendesk, and Jira, among others^[4]. That list is explicitly partial in the source and should be read as a sample of the gallery, not as the gallery.

When nothing prebuilt fits, the routes that remain are developer work rather than Copilot Studio features. A custom synced connector can be built with the Microsoft 365 Agents Toolkit or the Microsoft Graph connectors API, which requires a developer to define a schema, register the connection in Microsoft Entra ID, and write code to pull and push data^[4]. For a data source that is not reachable from the cloud, the Microsoft Graph connector agent securely indexes local content for on-premises sources^[4]. Microsoft's own advice on the choice is blunt and worth repeating in a design review: use prebuilt connectors when possible, and reserve custom development for unique or critical sources, because custom connectors offer flexibility but require maintenance.

When the answer is "no connector, and no admin"

Microsoft names the fallback rather than leaving you to invent one. If a Microsoft Copilot connector is not available, refer to Add Power Platform connectors as knowledge^[1]. That is a genuinely different mechanism with a different content path, not a workaround with the same properties, and choosing it changes freshness, data movement, and citations all at once. The section on choosing between indexed and live spells out what you are trading.

The takeaway is a sequencing rule. Nothing you can configure in Copilot Studio creates an indexed source; you are always selecting one that already exists. If it does not exist, your options are to get it created or to switch mechanisms.

The unit of a Copilot connector is not a file, it is an item. A Copilot connector defines a connection to an external data source and syncs content into Microsoft 365, using the Microsoft Graph connectors API to ingest items into the Microsoft Graph index. Each item includes content, metadata (like title and URL), and an access control list (ACL) that enforces permissions^[4]. Each of those three parts does different work later: content is what gets searched, metadata is what an answer cites and what a refinable property filters on, and the access control list is what makes one index serve many users safely.

Microsoft names three consequences of ingestion, and it is worth reading them as three separate guarantees rather than one. Unified index: the item becomes part of your organization's cloud search index, full-text searchable and processed by semantic indexing AI for relevance. Permission-based filtering: search and Copilot only show items to users who have access in the source system. Continuous sync: connectors periodically check for changes, so new, updated, or deleted content is reflected in the index, and admins can configure sync frequency and trigger full crawls as needed. The third one is where index freshness comes from: admins configure the sync frequency and can trigger a full crawl, and neither control appears anywhere on the agent's Knowledge page.

The counts that bound your agent

Two numbers apply. The Copilot Studio web app limit is 500 knowledge sources per agent across all types^[5], which Copilot connector sources share with every other source you added. The second number depends on orchestration mode: Microsoft's supported-sources table lists enterprise data reached through connectors as unlimited in generative mode and two per custom agent in classic mode^[3]. That asymmetry is the trap. A design validated under generative orchestration and later switched to classic silently stops searching everything past the second connector source, and no error announces it.

The takeaway: an item, not a document, is what the index holds, and keeping those items current is the connector's whole job. How many such sources one agent may draw on is decided by orchestration mode, not by the connector.

How well an indexed source answers is decided by one tenant-side artifact that never appears on the agent's Knowledge page: the search schema. Microsoft defines it as the structure of how content is collected from data sources, indexed, queried, and retrieved from the search index, containing crawled properties, search attributes, semantic labels, and aliases^[6]. Crawled properties are the source fields, so a work-ticket connector might expose ticketId, title, assignedTo, priority, status, and url. Search attributes then decide what the index may do with each one: searchable adds its value to the full-text index, queryable lets it be restricted in a query, retrievable lets it come back in results, and refinable lets an admin offer it as a filter, with the constraint that a refinable property cannot also be searchable. The figure below shows the three decisions one source field goes through.

Semantic labels, the part to argue about in a design review

Of the four things a schema holds, semantic labels are the one whose mapping most visibly changes what an answer looks like. A semantic label is a well-known tag published by Microsoft that you can add against a property in your schema, and adding a semantic label helps various Microsoft products understand the property and provide a better experience^[6]. Microsoft publishes the label set as a closed table: title, url, createdBy, lastModifiedBy, authors, createdDateTime, lastModifiedDateTime, fileName, fileExtension, and iconUrl. Two rules travel with them. All properties mapped to labels must be retrievable. And the label title is the most important label; assign a property to it to allow your connection to participate in the result cluster experience, and note that incorrectly mapping labels degrades the search experience^[6]. A connector that returns oddly-titled or unhelpful results is far more often a label-mapping problem than an agent problem.

Schema changes are not free

One constraint belongs in your head before you agree to a schema in a hurry: you cannot delete an existing property for a published connection, and to remove a property you must delete and recreate a connection^[6]. You also cannot remove a retrievable attribute from a property, and you cannot add or remove a refinable attribute. Adding a search capability requires a full crawl, and Microsoft recommends a full crawl after any schema update to avoid inconsistent item behavior. In practice this makes the connector schema a design decision with a rebuild cost attached, which is exactly the sort of thing to raise while the connection is still a plan.

The takeaway: the quality ceiling of a Copilot connector knowledge source is set on the tenant side, by schema and labels, and it is set once, with a rebuild cost attached to changing it. Raise it while the connection is still a plan, because after publication your options narrow to a full crawl or a recreated connection.

Every item in the index carries the access control list it had in the source system, and that is the entire access model. Microsoft states both halves: these connectors fully respect source-level permissions, ensuring that users only access content they are authorized to view^[1], and, on the index side, search and Copilot only show items to users who have access in the source system^[4]. Copilot Studio's knowledge documentation says the same thing from the agent's point of view: agent user authentication for knowledge sources means that when a specific user asks a question of the agent, the agent only surfaces content that the specific user can access^[3].

The useful way to hold this is that permission trimming, the same idea the planning pages use, is applied to the result set at query time using an authorization fact captured at index time. One index, one crawl, many different answer sets. You do not configure anything per user, and you cannot widen access from the agent side: if the asking user cannot open the item in Confluence, no Copilot Studio setting makes the agent quote it to them.

Which also means an unauthorized user gets silence

Here is the cost, and it is a diagnostic cost rather than a security one. A user without source permission is filtered out of the result set rather than told about it: permission-based filtering removes the item, and no error or refusal announces that it did. From the chat window, that is hard to tell from content that is not in the index at all. That is by design (the alternative would leak the existence of documents), and it is why an empty answer is never, on its own, evidence that a knowledge source is misconfigured.

Copilot Studio's knowledge surface has several causes that produce an identical errorless empty answer, and Configure custom knowledge works through the full set. What this page adds is the two causes specific to Copilot connectors: the asking user genuinely lacks source permission, and the agent's published channel is missing the delegated scope that lets it read external items at all. Those two look identical from the chat window and are distinguished by a single question, covered two sections down: does the failure affect one user or every user?

What this does not cover

Be careful about what "respects source permissions" claims. It is a statement about who may see an indexed item. It is not a statement about content that never made it into the index, about sensitivity labels applied after ingestion, or about what the tenant's data policies allow makers to attach in the first place. Microsoft points the last of those at a different control entirely: use Power Platform data policies to enable or disable specific knowledge sources by environment or tenant^[2]. A knowledge source can be perfectly permission-trimmed and still be one your environment forbids you to add.

The takeaway is a two-part test you can run in a review. Ask who the content belongs to in the source system, because that answer is what the agent will enforce. Then ask what the reader sees when the answer is "not you", because the answer is nothing, and a design that treats silence as success has no way to tell a working agent from a broken one.

For Copilot connector content, Microsoft explicitly recommends one agent setting to improve search results, and that setting is published under three different names. Its current, canonical name is Tenant graph grounding with semantic search, on the agent's Generative AI settings page. This guide shortens that to tenant graph grounding and uses no other name.

What it does: the setting determines whether your agent uses semantic search to improve search results, and it requires that the agent has generative orchestration turned on^[3]. Microsoft's recommendation for connector content is explicit rather than implied. For better search results with Microsoft 365 Copilot connectors, we recommend having a Microsoft 365 Copilot license in the same tenant as your agent, and turn on tenant graph grounding with semantic search^[1].

What it costs and what it requires

The prerequisites are published on the settings page, and so is the price tag. The feature requires the agent to share a tenant with a Microsoft 365 Copilot license, requires that a semantic index is configured for use, and to use a semantic index the Microsoft 365 Copilot license must be assigned to at least one user in the enterprise^[3]. It requires generative orchestration. And it comes at an extra cost. One reassurance sits alongside those: the agent maker does not need a Microsoft 365 Copilot license to create an agent with a semantic index. Microsoft also notes a trade rather than a free win: the retrieval is more precise and carries more context, but certain users and queries might experience a small increase in latency, and if you do not have a Microsoft 365 Copilot license in the same tenant, or you experience lower response quality, turn the feature off.

The file-size ceiling is published twice, with two numbers

On the same page, two sentences give different ceilings for the same pair of source types. The body states that when you turn on the feature and the maker has a Microsoft 365 license in the same tenant, the agent supports SharePoint and connectors containing files up to 200 MB^[3]. A note a few lines later states that SharePoint and Microsoft Copilot connectors support files up to 512 MB if they have PDF, PPTX, or DOCX extensions^[3]. The most likely reading is that 200 MB is the general ceiling and 512 MB is a file-type-specific one, but Microsoft does not say that, and the article does not reconcile the two. Do not build a sizing rule on either number without checking the behavior in your own tenant, and do not treat a question that hands you one of them as settled fact.

The other two names, and one dangerous near-name

The comparison article, which is older, tells you in its Copilot Studio checklist to ensure Turn on Work IQ and authentication are configured^[2], and repeats Turn on Work IQ as the setting to verify when a Graph source returns low-quality answers. The quotas article uses the same phrase in its SharePoint limits, and the troubleshooting article for SharePoint grounding calls the setting Enhanced search results. All three appear to describe the same toggle; none of the articles cross-references the others by name. Use the name this page settled on, recognise the aliases when you meet them, and do not key a design or an answer on the label.

The near-name is more dangerous than the aliases, because it is a genuinely different feature that also exists. Work IQ MCP is a preview Model Context Protocol tooling layer added under Tools as a Model Context Protocol server, requiring a Microsoft 365 Copilot license^[7], with servers such as Work IQ Mail, Work IQ Calendar, and Work IQ Teams governed by admins in the Microsoft 365 admin center. It is a tool, not a knowledge setting, and adding it does nothing for a Copilot connector's retrieval quality. If a scenario asks you to improve grounding on indexed connector content and offers "add the Work IQ MCP server" as an option, that is the distractor; the answer is the Generative AI setting. The MCP mechanism itself is Configure MCP tools.

The takeaway: tenant graph grounding is the quality lever for Copilot connector content, it has real licensing and cost preconditions, and its published name is the least reliable thing about it.

Publishing is where a working Copilot connector agent can stop working, and Microsoft's own diagnosis points at publishing, authentication settings, or scope rather than at the connector. Microsoft states the requirement in one sentence: you must configure agents that use Microsoft Copilot connectors as knowledge sources with the correct authentication settings when publishing to channels, and you must provide the ExternalItem.Read.All scope as part of the manual authentication setting^[1]. ExternalItem.Read.All is the Microsoft Graph delegated permission that lets the signed-in user read external items, which is exactly what a Copilot connector's indexed content is.

That scope goes in the Scopes field of Authenticate manually, alongside whatever else the agent needs, separated by the Scope list delimiter. Copilot Studio describes the field as the list of scopes that you want users to have after they sign in^[8], with the standing advice to set only necessary scopes. Two operational details save a debugging session. Authentication changes only take effect after the agent is published, so a corrected scope list that was never published is indistinguishable from a scope list that was never corrected. And the maker's own sign-in to the source has nothing to do with it: what is being authorised is the end user of the published channel, not the person who added the knowledge source.

Where the constraint appears

Now put that manual-authentication requirement beside the previous section's quality lever, because they are two values of one setting. Tenant graph grounding requires that the agent's user authentication is set to Authenticate with Microsoft, and if authentication is set to any other method you cannot change the setting^[3]. The quotas article says the same thing from the other direction: access to SharePoint documents and Turn on Work IQ do not support manual authentication^[5].

So the two published requirements select opposite values of that one setting, and no article publishes a rule for resolving the collision; what is published is what each authentication option gives you. Authenticate with Microsoft gives you the Teams + Microsoft 365 channel and native and custom app channels, and sets up Microsoft Entra ID authentication for Teams with no manual configuration^[8]; Copilot Studio's own guidance is that if you need to publish to channels other than Teams + Microsoft 365 but still want authentication, choose Authenticate manually. Read the two rules together and you get an order of investigation rather than a forced rule: settle the channels you must publish to, read what that implies for the authentication option, then check whether tenant graph grounding is still available to you. The figure below traces the two routes.

This is a place to be careful about what the documents actually say. Neither article states "you cannot have both", and neither describes the interaction at all. What is published is that the semantic-search setting is unavailable under manual authentication, and that channel publishing with connector knowledge is documented against the manual path. Treat the collision as a design question to verify in your target environment, not as a settled product rule you can assert.

Which failure looks like which

The difference between a scope problem and a permission problem is a counting question, and it is worth writing on the whiteboard.

• Every user, every question, from one channel: the published channel is missing ExternalItem.Read.All, or the authentication change was never published. Nothing about the source or the index is wrong.
• One user, every question: that user lacks permission in the source system. The access control list indexed with each item is doing its job.
• Every user, some questions: the likely causes are content that is not in the index, retrieval that is not finding it, or weak schema and labels. That is the previous sections' territory, not this one's.

The takeaway: at runtime, the connector is not the thing that gets authorised. The published agent is, and it is authorised per channel, once, and only after publishing.

The decision reduces to one question: must the answer be true of the source at the moment it is asked? If yes, no index will do it, however good it is, because retrieval is served from the last sync rather than from the source. If no, the index is almost always the better instrument. Everything below is elaboration on that.

Microsoft's own decision guide states both sides. Use synced Copilot connectors when you need to index large bodies of external content (ServiceNow KB, Jira, Confluence, GitHub, or Azure DevOps Services) to ground responses, and to benefit from semantic indexing and citations in responses, plus reuse in Microsoft Search and other experiences^[2]. Use Power Platform connectors when you need to fetch live data such as the status of ticket 1234, perform actions such as creating a case or updating an order, or ground an answer without copying data into Microsoft 365. Microsoft compresses it into one line worth memorising: if the goal is knowledge discovery and grounded question answering at scale, start with Copilot connectors; if the goal is real-time knowledge for grounding without copying, or transactional steps, use Power Platform connectors.

The four dimensions that actually discriminate

The comparison table above carries the full set; four of its rows do the real work in a decision, and they are named here exactly as they are named there.

Freshness. Copilot connector retrieval is served from the Microsoft Graph index, and the index is refreshed on the connector's sync cycle, not on the question. A correct answer about a ticket that was reassigned an hour ago is a perfectly normal outcome and not a defect. If every answer must reflect the source system at request time, the indexed path is disqualified before any other consideration.

Data movement into Microsoft 365. Synced connectors copy content into Microsoft 365 and Microsoft Graph. The real-time connector path exists precisely because that copy is sometimes forbidden: Microsoft describes it as indexing only metadata, such as table names and column names, with no data movement between systems^[9]. A residency or replication rule turns this into a hard constraint rather than a preference.

Citations. Copilot connectors give citations as a property of the mechanism. For Power Platform connectors, Microsoft describes citations as not inherent^[2]: actions return data, and the agent's response logic can cite grounding from real-time knowledge. When a compliance requirement says every claim must link to its source, that difference is the requirement, not a nicety.

Create or update operations. No knowledge source, of either kind, creates or updates anything. Grounding retrieves. If the requirement is to create or update a record, the answer is a tool or action, and indexing the same system does not get you halfway there.

Two failure shapes to recognise

The first is indexing a transactional system and expecting grounded answers to act on it. Indexing an order-management system tells the agent what an order looked like at crawl time; it does not let the agent change a quantity, and no amount of index tuning will make it. The mechanism has no write path.

The second is the mirror image: reaching for a live connector when the requirement was discovery. If users ask open questions in their own words across thousands of knowledge articles, a per-record API call has nothing to rank and no semantic index to rank with. That is the case Microsoft describes as content benefiting from semantic ranking, scoping, and citations.

The takeaway is that this is not a preference between two similar tools. The indexed path and the live path differ in where the content lives, when it is read, who can act on it, and whether the answer can cite anything. Pick the one whose properties the requirement names, and the rest of the design follows.

Microsoft answers the obvious question directly. Can both connector types ground the same agent? Yes. Many customers combine Copilot connectors for broad knowledge and Power Platform connectors for up-to-date answers and actions^[2]. It publishes the shape as a named scenario: index evergreen content such as policies and HR frequently-asked questions with Copilot connectors, and use Power Platform connectors for workflows and transactions such as create case and update asset.

The worked shape below is the service-desk version, and it is worth walking because each half has to earn its place. The agent carries a Copilot connector over the ServiceNow knowledge base, so "what is our split-tunnel VPN policy?" is answered from indexed articles with a citation the user can open. The same agent carries a ServiceNow Power Platform connector as a tool, so "raise a ticket for my VPN" creates an incident under the asking user's connection. Remove the connector and the agent can still create tickets but can no longer explain policy or cite it; remove the tool and it can explain the policy but can only tell the user to go and file the ticket themselves. Neither half substitutes for the other, which is the test for whether a two-mechanism design is real or decorative. The figure below shows the split.

The routing question, and who answers it

With generative orchestration on, you do not route the turn; the agent does. What you control is the material it routes with, which for a knowledge source is its selection metadata, the name and description the orchestrator reads. Two sources in one agent over the same vendor system therefore need descriptions that discriminate on the thing that actually differs. "ServiceNow" on both is a design that will disappoint you. "Published knowledge-base articles about IT policy and how-to guidance" against "Create and update ServiceNow incidents for the signed-in user" gives the orchestrator something to choose with.

Where the identities differ, and why it matters

The two halves do not share an identity model, and a design review should say so out loud. The indexed half is filtered by the access control list captured with each item, so what the user sees is whatever they could see in ServiceNow at crawl time. The tool half runs under the tool's credential mode, which decides whether the call uses the end user's credentials or the maker's. That means a user can legitimately be unable to read an article and still able to file a ticket, or the reverse. Both behaviors are correct; neither is inferable from the other. The tool-side identity work belongs to Connect to Power Platform connectors and to Plan enterprise integrations.

One caution about combining

A mixed design still lives under the counts from earlier: 500 knowledge sources per agent across all types, and, under classic orchestration only, two connector-based knowledge sources per custom agent. It also lives under the authentication constraint from two sections back, because that is a property of the agent and not of any one source. Check a mixed design against both, since neither is a per-source setting that adding a second mechanism escapes.

The takeaway: combining is the normal enterprise answer, not an advanced technique. Three things keep the two halves distinct: they answer different questions, they are described differently to the orchestrator, and they are governed by different identity rules.

The complaint arrives in a recognisable form: the connector is fine in Microsoft 365 Copilot and in search, and the agent knows nothing. Microsoft publishes a pitfalls list, and its connector entries are exactly this surface: a connection that is not displayed, answers that are unexpected or low quality, and a connector that works in Teams and Copilot but not in Copilot Studio. The figure below runs it top to bottom.

The source is not in the dialog. Ensure your admin creates the connector in the tenant, then add it by selecting Add knowledge then Advanced^[2]. Check Advanced first, because a configured connector that is simply not in the Featured list looks identical to one that does not exist. Only when it is absent from Advanced too is this a tenant problem.

The source is there, and the answers are poor. Verify semantic labels, indexing completeness, and the Turn on Work IQ setting; ensure the authentication configuration for the channels where you intend to publish your agent includes the appropriate scopes^[2]. Two of those three are tenant-side and are the schema work from earlier. The label mapping in particular is not cosmetic: Microsoft's own warning is that incorrectly mapping labels degrades the search experience.

The connector works in Teams and Copilot but not in Copilot Studio. Microsoft's diagnosis is that differences often come from publishing, authentication settings, or scope, for example a missing ExternalItem.Read.All scope, so check the channel configuration again^[2]. This is the one that most often reaches an exam question, because the symptom deliberately points away from the cause. The connector is healthy. The index is healthy. What is missing is a delegated permission on the published agent.

The question that orders the whole thing

Before any of the three, ask how the failure is distributed, because the answer usually points at one branch and away from the other two. All users failing on a channel is a publishing or scope problem. One user failing everywhere is a source-permission problem, and the access control list captured at index time is behaving correctly. All users failing on some questions is a content or schema problem.

What silence does not tell you

This is the point from Permission trimming happens inside the index above, restated because it is the single most reliable way to misdiagnose this surface: an empty answer with no error never identifies its own cause. Configure custom knowledge works through that family in full. The connector-specific members of it are the two named earlier — the asking user lacks source permission, and the published channel is missing the delegated scope — plus the ordinary case where the content is not indexed yet, since the tenant-side checklist puts completed indexing before the maker can add the source.

The takeaway is that almost nothing on this list is fixed in the agent. The maker-side surface for a Copilot connector is small by design: pick a source, pick a connection, add it. When it misbehaves, the fix is nearly always in the tenant's connector configuration or in the published agent's authentication, and knowing which one you are looking at is the skill.

Items on this subtopic almost always hand you a requirement in business language and ask which mechanism satisfies it. The discriminating words are reliable, so learn to read for them rather than for the product names, which appear in every option.

"Semantically indexed, with citations, reusable across Microsoft Search or Microsoft 365 Copilot." This is the Copilot connector signature, and no other mechanism on this page carries all three properties at once. A stem that mentions a large corpus of knowledge articles, wikis, or tickets and asks for grounded answers with references is asking for the indexed path. Watch for an option that offers a Power Platform connector as a tool, which returns data to an action rather than grounding an answer with citations, or a file upload, which never reaches the external system at all.

"Must reflect the current state", "real time", "at the time of the request". This disqualifies the index no matter how attractive the rest of the requirement looks. Retrieval is served from the Microsoft Graph index, so the answer is as fresh as the last sync. Route it to a real-time Power Platform connector knowledge source.

"Create", "update", "submit", "reassign". No knowledge source performs operations. If the requirement contains a verb that changes the source system, the answer is a tool or action, and "index the system with a Copilot connector" is the trap answer, because it is a plausible-sounding way to make the agent know about the system while doing nothing about the requirement.

"Without copying data into Microsoft 365", "data must not be replicated". A synced Copilot connector copies content by definition, so this phrasing rules it out and points at the no-copy path.

"Both". When a stem describes grounded answers and a transaction on the same vendor system, the answer is usually that one agent carries both mechanisms. Microsoft documents this explicitly, so an option claiming the two are mutually exclusive is wrong on its face.

The configuration traps

Three recur, and all three are about something other than the connector.

The first is the missing scope. A stem where the connector works in Teams or in Microsoft 365 Copilot but the published agent returns nothing is pointing at ExternalItem.Read.All and the manual authentication setting, not at the connector or the index. Read "works elsewhere, fails here" as a publishing-and-scope signal.

The second is the invisible source. A maker who cannot see a connector the admin swears is configured should try Advanced before anyone opens a support ticket. An option that jumps straight to recreating the connection skips the documented first step.

The third is the maker's own sign-in. Nothing you signed in with created the knowledge source — the administrator's connection already carried the source access — and what matters when a user asks a question on a published channel is that user's own authorisation. An option that proposes reconnecting the maker's connection to fix an end-user failure is treating one identity as the other.

Two things not to key on

The setting that improves retrieval quality for connector content is published under several names across current Microsoft articles: Tenant graph grounding with semantic search, Turn on Work IQ, and Enhanced search results. Recognise all three as the same toggle and answer on the behavior described, not the label. Separately, the file-size ceilings for connector content are published as both 200 MB and 512 MB on the same article, under different conditions that Microsoft does not reconcile, so treat a question that turns on that number with suspicion and prefer an option that does not depend on it.

The last habit worth building is a sequencing one. Read the requirement for freshness, for writes, and for data movement before you read the options. Those three answers pick the mechanism between them, and everything else in the stem is detail about how to configure the mechanism you have already chosen.