Article 35/50 — Copilot Connectors for Enterprise Knowledge

Architecture, Indexing, Security, and Integration with Microsoft 365 Copilot

Technical Series: From Zero to Enterprise AI Agent Architect

1. Introduction

Enterprise AI agents are only as useful as the information they can access.

An organization might store corporate policies in SharePoint Online, technical documentation in Confluence, incidents in ServiceNow, development tasks in Jira, and customer records in other business applications.

The challenge is not simply connecting these systems to an AI model. It is making their information discoverable, relevant, secure, and available in the right context.

Microsoft 365 Copilot connectors address this challenge by extending Microsoft 365 Copilot and supported intelligent experiences with knowledge from external enterprise systems.

Rather than forcing organizations to migrate all their content into SharePoint, connectors provide mechanisms for integrating existing repositories into the Microsoft 365 knowledge ecosystem.

The architecture supports two primary integration models:

• Synced connectors, which ingest and index external content into Microsoft Graph.
• Federated connectors, which retrieve external content at query time through Model Context Protocol (MCP), without indexing it into Microsoft Graph.

Microsoft also offers a self-service configuration model for certain synced connectors, currently in preview with limited availability.

Understanding these models is essential for designing secure enterprise agents, selecting the correct integration strategy, and avoiding unnecessary complexity.

This article examines connector architecture, indexing, metadata, identity, authorization, Retrieval, Grounding, Copilot Studio integration, governance, troubleshooting, and licensing.

Our primary enterprise scenario combines SharePoint Online and Confluence as knowledge sources for a Microsoft Copilot Studio Agent.

2. What Is a Microsoft 365 Copilot Connector?

A Microsoft 365 Copilot connector is an integration capability that makes external enterprise information available to supported Microsoft 365 experiences.

Its purpose is to extend the information available for search, discovery, and AI-assisted reasoning.

Consider an organization with these repositories:

Without external knowledge integration, an Agent may be unable to retrieve relevant information from these systems.

A Copilot connector provides a supported path to make selected information available, subject to the connector model, supported experience, authentication, and authorization configuration.

However, an important distinction must be established:

A Copilot connector is not automatically an Action, a workflow, or a general-purpose API execution mechanism.

In the indexed knowledge scenario, its principal responsibility is making external content retrievable.

The Agent subsequently uses that content to produce grounded answers.

Federated connectors introduce additional capabilities, including live retrieval and, where supported, operations against external systems. These capabilities must be evaluated separately from indexed knowledge integration.

3. Copilot Connectors vs. Power Platform Connectors

The word connector appears throughout the Microsoft ecosystem, but different connector technologies solve different architectural problems.

Microsoft’s Copilot Studio documentation differentiates indexed Copilot connector knowledge from real-time Power Platform connector knowledge.

Architectural interpretation

A synced connector is a good candidate when an organization wants to make a substantial repository of relatively stable documentation discoverable.

A real-time integration is generally more appropriate when the information changes frequently, is transactional, or must be retrieved directly from its authoritative source.

For example:

• What is our corporate remote-work policy? — Indexed Knowledge Source.
• What is the current status of incident INC-1042? — Real-time query.
• Create an incident for this service outage. — Action or Tool.

These three requirements should not automatically use the same integration architecture.

4. The Synced Connector Architecture

A synced connector follows an ingestion-and-indexing model.

Conceptual data flow:

External enterprise repository → Synced Copilot connector → Content ingestion, metadata, and ACL mapping → Microsoft Graph external content index → Authorized Retrieval → Grounding → Microsoft 365 Copilot or Copilot Studio Agent.

4.1 Source authentication

The connector first needs permission to read information from the external system.

Depending on the source, this might involve an API token, service account, administrative authorization, or another supported authentication method.

These credentials belong to the ingestion process.

They are not necessarily the credentials used by the person asking the Agent a question.

4.2 Content ingestion

The connector reads the configured content scope.

For a Confluence deployment, that scope might include selected spaces, pages, and blog posts, depending on the connector’s supported configuration.

The connector extracts content and associated metadata.

4.3 Schema and metadata

Indexed items can include properties such as title, content, URL, timestamps, and other source-specific attributes.

For custom connectors, the external item schema determines how content is represented in Microsoft Graph.

4.4 Permission mapping

The connector must represent the intended visibility of the source content.

A document available only to a particular department must not become accessible to the entire tenant merely because it was indexed.

4.5 Indexing

Microsoft Graph stores the external items and makes them available to supported search and Copilot experiences.

4.6 Retrieval and Grounding

When an authorized user asks a question, the consuming experience can retrieve relevant indexed content.

The language model uses the retrieved material as context when generating its answer.

This is the essential relationship between connectors and Retrieval-Augmented Generation (RAG).

5. Microsoft Graph External Items and Schema Design

A custom synced connector uses Microsoft Graph structures to represent external content.

Three concepts are especially important:

External connection: Represents a logical connection to an external content source.

External item: Represents an indexed piece of content from that source.

Schema: Defines the properties and search characteristics of those items.

For example, an architecture document from an external repository might conceptually be represented as follows:

{
  "id": "ARCH-001",
  "properties": {
    "title": "SharePoint Integration Architecture",
    "sourceSystem": "Confluence",
    "documentType": "Technical Architecture",
    "department": "IT",
    "lastModified": "2026-10-15"
  },
  "content": {
    "type": "text",
    "value": "Architecture overview and integration requirements..."
  }
}

This is a simplified conceptual illustration, not a complete Microsoft Graph API request. A production external item requires the appropriate schema, content representation, and access-control configuration.

Why metadata matters

Consider two documents:

1. SharePoint Integration Architecture, last updated in 2022.
2. SharePoint Integration Architecture, last updated in 2026.

Without useful metadata, the retrieval process may have difficulty distinguishing the intended version.

Metadata can improve discoverability, filtering, relevance, and source interpretation.

When designing a custom connector, architects should consider which properties must be searchable, queryable, or refinable, and which semantic labels should be assigned.

Architectural recommendation

Do not index every available property simply because it exists.

Select metadata that contributes to retrieval quality, governance, or user understanding.

A small, consistent schema is often more maintainable than an extensive collection of poorly governed fields.

6. Semantic Indexing and Retrieval Quality

Traditional keyword search relies heavily on matching the terms used in a query.

Semantic retrieval can improve results by considering contextual meaning and relationships between concepts.

For example, a user asks:

Which internal documentation explains how our applications authenticate to SharePoint Online?

The relevant document might be titled:

Enterprise Identity and Token Acquisition Architecture.

The document may discuss Microsoft Entra ID, OAuth 2.0, delegated permissions, application permissions, and access tokens without repeating the user’s exact wording.

Semantic indexing can help make such material discoverable.

However, semantic indexing does not eliminate the need for good source material.

An Agent cannot reliably answer a question using documentation that is incomplete, contradictory, obsolete, or inaccessible.

Five factors affecting answer quality

A well-designed connector does not guarantee a correct answer.

It establishes the conditions under which useful grounding can occur.

7. Security Architecture: Ingestion Identity vs. Retrieval Identity

Security is one of the most important aspects of enterprise connector design.

The architecture involves at least two distinct security contexts.

Ingestion identity

The ingestion process accesses the external source.

Its credentials must be able to read the configured content.

Depending on the connector and external system, these permissions may be broader than those of an individual end user.

This creates an important responsibility: the connector must correctly preserve or reproduce the intended visibility of indexed items.

Retrieval identity

The person interacting with Copilot or the Agent must be authorized to retrieve the content.

For permission-aware synced connectors, indexed access-control information is used to restrict content visibility.

Microsoft’s administration interface distinguishes between:

• Only people with access to this data source
• Visible to everyone

The second option can expose indexed content to users who could not access the original repository.

Example: Restricted technical documentation

Suppose a Confluence space contains security architecture documents.

Only members of the Security Architecture team should access them.

A correctly configured permission-aware connector must preserve that restriction for retrieval.

The fact that a tenant administrator can ingest the documents does not mean that every employee should see them in Copilot.

Identity mapping

The connector may need to associate external identities with Microsoft Entra ID users or groups.

This can become complicated when:

• External users have different email addresses.
• Service accounts own documents.
• Source groups do not correspond directly to Entra ID groups.
• Users have been renamed or migrated.
• Source permissions are inherited or dynamically calculated.

Architectural recommendation: Validate identity mapping and item-level access before exposing a connector to production users.

A successful ingestion test is not a sufficient security test.

8. Permission Changes and Synchronization Risk

Consider a document that was initially accessible to the entire IT department.

Later, its permissions are restricted to a small security team.

In a synced architecture, the connector must propagate the updated access-control information.

Until that change is reflected in the index, there may be a period during which indexed permissions differ from the source.

The precise behavior and delay depend on the connector and synchronization process.

This is why permission synchronization should be part of the security design, not merely an operational detail.

Recommended validation

Test at least three situations:

The third test is especially important for sensitive repositories.

For highly dynamic permissions or data that must never be represented by a synchronized copy, evaluate whether a supported real-time architecture is more appropriate.

9. Federated Copilot Connectors

Federated connectors use a fundamentally different model.

Rather than copying content into Microsoft Graph, they retrieve information from the external system when a query occurs.

Microsoft documents the federated connector model as MCP-based.

Conceptual data flow:

Authenticated user → Microsoft 365 Copilot → Federated connector / MCP → External enterprise service → Authorized live response → Grounded answer.

Advantages

Federated retrieval can reduce the need to maintain a separate indexed copy of external content.

It is especially interesting for dynamic information and systems where the external service should remain the authoritative source.

Trade-offs

The architecture becomes dependent on external service availability, network latency, authentication, API behavior, and query-time authorization.

A slow external system can affect the user experience.

A connector may also expose only the capabilities that its MCP implementation supports.

Important boundary

Federated connectors should not be treated as interchangeable with synced connectors across every Copilot experience.

Support and licensing depend on the target experience.

For this article, the detailed Copilot Studio implementation focuses on synced connector knowledge, which has explicit Microsoft documentation for that scenario.

Federated integration and MCP architecture deserve separate technical treatment in Articles 38–40.

10. Self-Serve Synced Connectors

Microsoft also documents self-serve sync connectors, currently in preview and available to a limited set of customers.

Unlike tenant-wide synced connections configured by an administrator, self-serve connections are established by individual users.

Each user authenticates to the external service using their own credentials.

Only that user’s accessible content is synchronized, and the indexed content is available to that user rather than to the entire organization.

Comparison

Self-serve synchronization should not be confused with federated retrieval.

Both may use user-level credentials, but self-serve synchronization still creates indexed content.

Governance implications

Administrators should decide whether individual users may establish external content connections.

This decision involves data classification, consent, compliance, supported services, and organizational policy.

A convenient self-service feature does not remove the need for information governance.

11. Enterprise Scenario: SharePoint Online + Confluence

Consider a multinational organization with two primary knowledge repositories.

SharePoint Online contains corporate policies, operating procedures, employee training materials, and Microsoft 365 technical documentation.

Confluence contains application architecture decisions, software development standards, integration specifications, and engineering knowledge.

The organization wants an Agent named Enterprise Technical Knowledge Assistant.

Its purpose is to answer technical questions using both repositories while respecting existing permissions.

11.1 Proposed architecture

The architecture consists of:

• SharePoint Online, accessed through a native SharePoint Knowledge Source.
• Confluence, integrated through a Synced Copilot connector.
• Microsoft Graph external content indexing for Confluence documents.
• A Microsoft Copilot Studio Agent configured with Instructions and Knowledge Sources.
• Authenticated employees interacting with the Agent.

The architectural objective is to reuse the native SharePoint integration while extending the Agent with external knowledge.

There is no requirement to copy SharePoint documents into Confluence, duplicate them in Dataverse, or introduce a custom Microsoft Graph application.

11.2 Example questions

The Agent should be able to answer questions such as:

• What are the approved authentication patterns for SharePoint Online integrations?
• Where is our technical documentation for Microsoft Entra ID application registrations?
• Which corporate policy governs access to confidential engineering documents?
• What are the documented standards for integrating SPFx applications with external APIs?

The Agent should retrieve relevant content, identify its source, and avoid inventing policies or implementation details.

11.3 Why no Power Automate?

The requirement is information retrieval.

No business record needs to be created, updated, or deleted.

Introducing Power Automate at this stage would add an unnecessary execution layer.

Power Automate becomes relevant when the Agent must perform a business operation or when a supported connector-based approach cannot satisfy a particular integration requirement.

12. Configuring a Synced Connector in Microsoft 365

Microsoft documents deployment of synced connectors through the Microsoft 365 admin center.

The following sequence is a reference implementation rather than a substitute for the source-specific deployment guide.

Phase A — Administrative preparation

1. Identify the external repository and confirm that a supported connector exists.
2. Verify tenant licensing, administrative prerequisites, and source credentials.
3. Define the content scope and intended audience.
4. Determine how source permissions will map to Microsoft Entra ID identities.

For our scenario, the source is Confluence.

Before creating the connection, the administrator should establish which spaces may be indexed and whether restricted spaces require separate treatment.

Phase B — Connection configuration

Navigate to:

Microsoft 365 admin center → Copilot → Connectors

Select the relevant connector and follow its configuration experience.

For connectors offering Custom setup, review the available configuration sections, including Users, Content, and Sync.

The exact settings vary by connector.

Phase C — Security configuration

For a permission-restricted enterprise repository, select the model that respects source-level access.

Avoid organization-wide visibility unless the content is genuinely intended for every user.

Microsoft documents that changing the access-permission model of an existing connection is not supported directly in certain connector configurations. Administrators may need to delete and recreate the connection.

This makes permission planning important before initial deployment.

Phase D — Index validation

After configuration, verify that the connector has ingested the expected content.

Do not proceed directly to publishing an Agent.

First confirm that relevant items are indexed, discoverable, and protected by the expected permissions.

13. Adding Copilot Connector Knowledge to Copilot Studio

Once the tenant administrator has configured the connector, an Agent maker can add the connection as a Knowledge Source.

Microsoft’s documented procedure for agents using the standard harness is:

1. Open the Agent in Copilot Studio.
2. Select Add knowledge from Overview, Knowledge, or a Generative Answers node.
3. Select the relevant Copilot connector. If necessary, use Advanced.
4. Choose the existing connection and select Add to agent.

The Agent then has access to the configured external knowledge source, subject to the runtime’s authentication and authorization requirements.

Authentication considerations

For supported channel publishing configurations that use manual authentication, Microsoft documents the ExternalItem.Read.All scope.

This scope relates to reading external items through Microsoft Graph.

It must not be interpreted as permission to bypass item-level authorization.

The application permission model, user authentication, consent requirements, and source ACLs must be evaluated together.

Recommended Agent Instructions

For our example Agent, a minimal instruction set might be:

You are an Enterprise Technical Knowledge Assistant.
Answer questions using the configured enterprise
knowledge sources, including SharePoint Online and
approved external repositories.
Prioritize retrieved evidence over general assumptions.
When relevant sources are available, identify them
and provide citations.
If the available knowledge does not support an answer,
state that the information could not be verified.
Do not invent corporate policies, procedures,
technical standards, or security requirements.
Do not claim to have performed operations against
enterprise systems.
Respect the user's authorized access to information.

These Instructions establish behavioral expectations.

They are not an authorization mechanism.

Security must be enforced by the underlying platform and connected systems, not by prompt text.

14. Testing Retrieval, Grounding, and Authorization

An enterprise connector should be tested at multiple layers.

Test 1 — Source availability

Ask a question that can be answered only by a specific Confluence document.

Expected result: The Agent retrieves relevant content and provides a grounded answer.

If the answer is unavailable, inspect indexing and source configuration before changing the Agent Instructions.

Test 2 — Source attribution

Ask a question whose answer exists in both SharePoint and Confluence.

Expected result: The Agent uses relevant evidence and provides appropriate citations where the experience supports them.

Inspect whether the response combines the sources accurately or introduces unsupported conclusions.

Test 3 — Unauthorized access

Use an account without permission to access a restricted Confluence document.

Ask a question designed to retrieve that document.

Expected result: Restricted content is not disclosed.

Test 4 — Permission revocation

Remove a test user’s access at the source.

After the relevant synchronization has completed, repeat the query.

Expected result: The revoked user can no longer retrieve the restricted indexed content.

Test 5 — Missing information

Ask a question that is not answered by the configured repositories.

Expected result: The Agent acknowledges insufficient evidence instead of fabricating an internal policy.

Test matrix

A production readiness assessment should record test identities, expected outcomes, actual results, and supporting evidence.

15. Troubleshooting Common Connector Problems

Connector troubleshooting should begin with the layer most likely to explain the failure.

Problem A — The connector is not visible in Copilot Studio

Possible causes include an unconfigured tenant connection, unsupported availability, or restrictions imposed by administrative policy.

Check the Microsoft 365 admin center first.

Then inspect Add knowledge → Advanced in Copilot Studio.

Do not immediately build a custom connector to replace a connection that has not been configured correctly.

Problem B — The connector exists, but expected documents are missing

Investigate the source scope, ingestion status, content eligibility, and synchronization.

If only some documents are missing, compare their properties and permissions with those of successfully indexed documents.

Problem C — The Agent produces incomplete answers

First verify that the required evidence exists and is retrievable.

Then examine metadata, semantic labels, source quality, and Agent Instructions.

Problem D — The Agent works in one experience but not another

Check whether the target experience supports the connector and whether the Agent’s authentication configuration is correct.

For Copilot Studio channel publishing, investigate the required scopes, including ExternalItem.Read.All where applicable.

Problem E — Unauthorized users can retrieve content

Treat this as a security incident, not a prompt-engineering problem.

Inspect the connection’s access-permission configuration and source ACL mapping.

If the connection was configured with organization-wide visibility unintentionally, follow Microsoft’s documented remediation process.

16. Governance and Enterprise Operations

A production connector becomes part of the organization’s information architecture.

It should have a defined owner, documented purpose, approved data scope, security classification, and operational responsibilities.

Governance checklist

Data residency and compliance

Indexed content is processed within the Microsoft 365 connector architecture rather than remaining exclusively in the original repository.

Consequently, data handling, residency, compliance, and retention requirements should be reviewed for the specific connector and tenant.

Federated retrieval avoids storing a synchronized content copy in Microsoft Graph, but it does not eliminate all processing, logging, compliance, or external-service considerations.

The choice between indexing and federation is therefore a governance decision as well as a technical one.

17. Licensing and Capacity Considerations

Licensing affects which connector models can be used and where their content can appear.

According to Microsoft’s prerequisites documentation, the following distinctions apply.

Microsoft also lists Microsoft 365 E7 as an eligible licensing path in its current documentation.

These distinctions matter because an organization may be able to index external content for Microsoft Search without automatically being entitled to use the same content for every Copilot grounding scenario.

Microsoft documents that synced connector indexing does not incur an additional indexing charge for tenants with Microsoft 365 licenses, while usage, feature availability, semantic capabilities, and capacity remain subject to applicable licensing conditions.

Architectural recommendation: Validate the tenant’s licensing model and the exact target experience before committing to a connector design.

Do not assume that licensing for Microsoft 365 Copilot, Copilot Studio, and federated connectors is interchangeable.

For commercial projects, pricing and consumption estimates should be confirmed against current Microsoft documentation and the organization’s licensing agreement.

18. When Should You Build a Custom Copilot Connector?

A custom synced connector may be appropriate when the organization maintains a proprietary repository that is not supported by an existing connector.

For example, a company might have a legacy C# document management application with a SQL Server database and an internal REST API.

If its documents need to be searchable across Microsoft 365, a custom synced connector could be considered.

However, custom development introduces responsibilities for:

• External connection and schema design.
• Content ingestion and updates.
• Source identity mapping and ACL representation.
• Error handling and synchronization.
• Operational monitoring and maintenance.

Before building one, evaluate simpler alternatives.

A custom connector is justified by a specific capability gap, not merely by the availability of Microsoft Graph APIs.

19. When NOT to Use Copilot Connectors

Copilot connectors are not the correct answer to every enterprise integration requirement.

If an organization already stores its authoritative documentation in SharePoint Online, adding an external connector to access the same documents may introduce duplication without meaningful benefit.

If the requirement is to update a SharePoint list item, an indexed knowledge connector is not the appropriate execution mechanism.

If the requirement involves precise calculations, strict transactional consistency, or guaranteed business rules, a deterministic application or API may be preferable.

If sensitive data cannot be synchronized outside its original system, an indexed architecture may be unsuitable.

The decision should begin with the business requirement:

Does the Agent need to know something, retrieve something current, or do something?

Those are different architectural problems.

20. Architectural Decision Framework

The following framework summarizes the main considerations.

Recommended enterprise pattern

For organizations with substantial SharePoint Online investments, a practical architecture is:

SharePoint native Knowledge Sources + Synced Copilot connectors for external documentation + real-time connectors or Actions for operational systems.

This pattern separates knowledge retrieval from business execution and avoids treating every integration as a custom development project.

21. Learning Journey — Where We Are and What’s Next

Current position: Article 35 of 50 — 70% of the roadmap.

Article 35 establishes the foundation for understanding indexed external enterprise knowledge.

Article 36 will examine real-time Power Platform connector knowledge, including connection identities, retrieval behavior, freshness, security, and architectural trade-offs.

Articles 38–40 will explore MCP and its role in federated and custom agent integration architectures.

22. Final Technical Summary

23. Conclusion

Microsoft 365 Copilot connectors are an important building block for enterprise AI architecture.

They enable organizations to extend Microsoft 365 knowledge experiences beyond SharePoint Online and other native Microsoft repositories without requiring wholesale migration of external content.

The synced model provides indexed enterprise knowledge, metadata-driven discovery, and integration with Microsoft Graph.

The federated model introduces a different approach, retrieving external information at query time through MCP without creating a synchronized Graph content index.

Neither model eliminates the need for careful identity, authorization, and governance design.

For enterprise architects, the most important principle is that connecting a source, retrieving information, and executing a business operation are three distinct capabilities.

A well-designed Agent uses the simplest supported integration that satisfies the business requirement while preserving security boundaries.

In our SharePoint Online and Confluence scenario, the appropriate initial solution is a native SharePoint Knowledge Source combined with a permission-aware synced Copilot connector for Confluence.

No custom API, Microsoft Graph application, Dataverse database, or Power Automate flow is necessary to establish this foundational knowledge architecture.

The result is a focused, maintainable Agent design that can later be extended with real-time knowledge and Actions when those capabilities are genuinely required.

24. Official Microsoft Documentation

The following Microsoft Learn references provide the technical foundation for this article.

1. Microsoft 365 Copilot connectors overview
2. Prerequisites for deploying connectors
3. Deploy connectors in the Microsoft 365 admin center
4. Manage access permissions for connectors
5. Add Copilot connectors as a knowledge source
6. Copilot connectors versus Power Platform connectors as knowledge sources
7. Manage self-serve sync connector availability
8. Microsoft Graph external content and connector architecture

Technical content prepared in November 2026. Preview capabilities, licensing eligibility, and administrative interfaces may change.