Book an audit →
IT specialist configuring Copilot connectors

Graph Connectors for Copilot: IT Leader’s Practical Guide

Microsoft 365 Copilot connectors let you bring external line-of-business data into Copilot either by indexing it (synced model) or by fetching it live at query time (federated model). For most mid-market professional-services firms, the right starting point is a focused synced connector proof-of-concept targeting one high-value knowledge repository, such as matter files, client engagement docs, or a billing knowledge base. Reserve the federated model for regulated or live data that legally or operationally cannot leave its source system.

TL;DR:

  • Synced connectors index external content into Microsoft Graph for semantic search and Copilot reasoning. Best for knowledge repositories, matter files, and searchable documentation.
  • Federated connectors fetch live data at query time via Model Context Protocol (MCP). Best for regulated, real-time, or source-locked data.
  • Start narrow: pick one high-frequency data object type, run a 4–8 week PoC, and measure time-to-answer improvement and recoverable billable hours.
  • Next step: map your top three staff queries that Copilot fails today, then select the connector model and data source that closes that gap.

Table of Contents

What connector model should you use for Copilot?

Microsoft 365 Copilot supports two primary connector models: synced connectors, which ingest and index external content into Microsoft Graph for semantic search and Copilot reasoning, and federated connectors, which perform query-time fetches without indexing. Choosing the wrong model does not just affect performance — it can either expose sensitive data you never intended to index or leave critical information effectively invisible to Copilot.

Synced vs. federated: what actually differs

Capability Synced connector Federated connector
Data movement Ingested into Microsoft Graph index Stays at source; fetched at query time
Semantic indexing Yes (content, title fields) No
Copilot grounding quality High (ranked, contextual results) Moderate (real-time, citation-based)
Authentication model App-level, admin-consented OAuth 2.0, user-level or app-level
Latency Low (pre-indexed) Higher (live fetch per query)
Best for Knowledge repos, matter docs, policies Live financial data, regulated records
Data residency control Data copied to Microsoft Graph Data never leaves source

The practical decision path is straightforward. Choose synced when your team needs Copilot to discover content across a corpus, when semantic search quality matters, and when the data can be copied to Microsoft Graph under your data governance policy. Choose federated when the data must remain at source for regulatory reasons, when it changes too frequently to index usefully, or when user-level authorization at query time is a hard requirement.

For a law firm, this often means synced connectors for precedent libraries and standard operating procedures, and federated connectors for live matter billing records in a practice management system. An accounting firm might index client engagement templates via synced while keeping live general ledger data federated.

Pro Tip: Before committing to a model, run a quick data classification exercise. If any field in the target dataset is subject to attorney-client privilege, HIPAA, or SOC 2 scope, involve your compliance officer before scoping the connector. Federated connectors eliminate the indexing risk entirely for those datasets.

How do Copilot connectors actually work?

The architecture flows in one direction: data source to connector to Microsoft Graph to Copilot surface. Understanding each stage tells you where to invest implementation effort and where failures hide.

Team reviewing connector architecture diagrams

For synced connectors, the pipeline starts with an externalConnection, which is the logical container registered in Microsoft Graph that holds your schema and ingested items. Inside that connection, you define an externalItem schema — the field definitions, property types, and semantic labels that tell the indexer what each piece of content means. Items are ingested as externalItem objects with a content property (the full text Copilot reasons over), a properties bag (structured metadata), and an ACL (the permission list that controls who can see each item).

Semantic indexing improves retrieval quality by enabling approximate and contextual matches and understanding relationships between data points. The content and title fields are the primary indexed fields. Semantic labels — like title, url, createdBy, and lastModifiedDateTime — help Copilot interpret metadata correctly, though they affect filtering and display rather than the semantic index itself.

Copilot connectors act as essential knowledge sources and must be added at the agent level or via generative answers nodes to ground Copilot and custom agents in line-of-business data. Without a connector, Copilot reasons only over standard Microsoft 365 content — emails, Teams messages, SharePoint files the user already has access to. Connectors extend that corpus to proprietary databases, external SaaS tools, and on-premises repositories.

The urlToItemResolver is a component many teams skip and later regret. Adding a urlToItemResolver allows Copilot to detect shared URLs and user activity data helps improve item ranking in search and Copilot answers. Without it, items may be indexed but rank poorly in Copilot responses.

For on-premises sources, the Microsoft Graph connector agent sits between your internal network and the Microsoft Graph ingest endpoint. It handles crawl scheduling, delete/difference detection, and identity mapping for ACL stamping. For cloud-to-cloud connectors, no agent is required — the connector calls the Graph API directly.

Sysadmin typing in server room setup

Copilot Studio and the Microsoft 365 Agents Toolkit integrate connectors as knowledge sources at the agent level. When a user asks a question, Copilot retrieves semantically relevant items from the index, applies security trimming (ACL check), and surfaces citations inline in its response.

How to build a custom synced Copilot connector

This is the implementation path most IT teams at professional-services firms will follow for their first connector PoC. The steps below assume a cloud-hosted data source; on-premises variations are noted where they diverge.

  1. Register an Azure AD application. Create an app registration in Entra ID, grant the ExternalConnection.ReadWrite.OwnedBy and ExternalItem.ReadWrite.OwnedBy Microsoft Graph application permissions, and obtain admin consent. This is the identity your connector uses to write to Microsoft Graph.

  2. Create the externalConnection. POST to /external/connections with a unique id, a display name, and a description. The connection ID cannot be changed after creation, so name it deliberately (e.g., matterfiles-prod).

  3. Define the schema. POST to /external/connections/{id}/schema. Map your source fields to typed properties (String, DateTime, Boolean, Int64). Apply semantic labels where they fit: title, url, createdBy, lastModifiedDateTime, fileName. Mark high-value text fields as isSearchable: true and isContent: true. The content property is what Copilot reads when generating answers — populate it with the richest, most relevant text from each item.

  4. Implement ingestion. PUT each item to /external/connections/{id}/items/{itemId}. Include the content object (type text or html), the properties bag, and the acl array. Batch ingestion in parallel where your source API allows; the Graph API supports concurrent item writes.

  5. Stamp ACLs correctly. Each acl entry specifies a principal (user, group, or everyone), an access type (grant or deny), and an identity source (azureActiveDirectory or onPremisesActiveDirectory). Mirror your source system’s permissions exactly. A mismatch here means users either cannot see content they should or — worse — can see content they should not.

  6. Add urlToItemResolver. Update the connection to include a urlToItemResolver that maps source URLs back to item IDs. This is required for Copilot to surface items when users share links and for improving ranking signals.

  7. Deploy the connector agent (on-premises only). Download the agent from the Microsoft 365 admin center or the SDK docs. Install it on a Windows Server with outbound HTTPS access to Microsoft Graph. Configure it with your app registration credentials — use a certificate, not a client secret, in production.

  8. Enable inline results. In the Microsoft 365 admin center, navigate to Search & Intelligence, find your connection, and enable it for inline results in Copilot. Without this step, indexed content will not surface in Copilot responses even if it appears in Microsoft Search.

  9. Validate and monitor. Run test queries in Copilot and Microsoft Search. Confirm items appear, citations are correct, and ACLs are trimming as expected.

Pro Tip: The most common reason ingested content stays invisible in Copilot is a missing or misconfigured urlToItemResolver, combined with no user activity signals. Add both before your first validation query. Also, schema changes after initial ingestion require a full re-crawl — plan your schema carefully before the first ingest run, because retrofitting it costs time.

For SDK and code samples, the Copilot connectors SDK overview covers the agent download, TypeScript and .NET sample repos, and the ingestion SDK. The GitHub samples under microsoft-graph/msgraph-connectors-samples are the fastest starting point for a PoC.

How do federated connectors handle live data?

Federated connectors use the Model Context Protocol (MCP) to fetch data at query time. When a user asks Copilot a question, Copilot calls the federated connector’s MCP server, which queries the source system in real time and returns a structured response. That response is included in Copilot’s context window alongside any indexed content, and Copilot cites the MCP server response inline.

Authentication patterns

Federated connectors support two auth patterns. Delegated (user-level) auth uses OAuth 2.0 with the signed-in user’s identity, meaning the connector queries the source system as that user and inherits their permissions. This is the right choice when source-system row-level security must be preserved at query time. Application-level auth uses a service principal, which is simpler to implement but requires careful scoping to avoid over-permissioning.

For most professional-services scenarios involving regulated data, delegated auth is the safer default. It ensures that a partner who queries a federated connector for client billing records sees only the records their source-system role permits.

Performance and latency

Because federated connectors fetch live, every Copilot query that triggers the connector adds a round-trip to your source system. For APIs with sub-200ms response times, this is negligible. For slower systems, consider response caching at the MCP server layer with a short TTL (30–60 seconds for near-real-time data). Avoid federated connectors for sources with response times above 2–3 seconds — users will notice the delay in Copilot’s answer latency.

One limitation worth stating plainly: federated connectors do not benefit from semantic indexing. Copilot cannot perform approximate or contextual matches across a federated corpus the way it can with indexed content. The connector must return well-structured, relevant responses to each query, because Copilot cannot compensate for a poorly scoped MCP response the way the semantic index can compensate for imperfect queries against indexed content.

Which prebuilt connectors cover common enterprise sources?

Microsoft and its partners provide more than 100 prebuilt connectors covering file stores, enterprise SaaS apps, and developer platforms. Before scoping a custom connector build, check the connector gallery — a prebuilt connector cuts PoC time from weeks to days.

Common prebuilt connectors relevant to professional-services firms, mapped to their primary use cases:

  • SharePoint — intranet knowledge bases, policy libraries, engagement templates, and standard operating procedures. Often the first connector to enable because the content is already in Microsoft 365.
  • ServiceNow — IT incident tracking, change management records, and internal service catalog. Useful for IT-heavy consulting and engineering firms.
  • Salesforce — client relationship data, opportunity history, and account notes. Valuable for business development and client-facing teams at consulting firms.
  • Jira — project and issue tracking, sprint history, and engineering backlogs. Relevant for technology consulting and software engineering practices.
  • Azure DevOps — code repositories, work items, pipeline history, and release notes. Primarily useful for internal IT teams and software-focused practices.
  • Google Drive / Box — external file stores for firms that maintain hybrid cloud document environments alongside Microsoft 365.
  • Network file shares and SQL databases — on-premises repositories requiring the connector agent; common in accounting and legal firms with legacy document management systems.

For HR and payroll systems, prebuilt connectors are less common. Most firms in this category build a custom synced connector against their HRIS API, indexing only non-sensitive fields (role, department, skills) and excluding compensation data entirely.

The Copilot connectors gallery is the canonical starting point. Filter by category and check whether a Microsoft-built or partner-built connector exists before writing a single line of custom code. For law firms specifically, the intersection of compliance requirements and data sensitivity means it is worth reviewing why specialized data governance matters for legal practices before selecting which sources to index.

How do you secure connector data and stay compliant?

Security in Copilot connectors is not a post-deployment concern. It is a design constraint that shapes every schema and ingestion decision.

ACL stamping is the foundation. Every externalItem must carry an ACL that mirrors the source system’s permissions. Microsoft Graph applies security trimming at query time — users only see indexed items their ACL grants them access to. If you ingest an item with an overly permissive ACL (or no ACL), that item becomes visible to everyone with access to Copilot. For a law firm, that could mean a paralegal seeing a partner’s privileged communication. Map source permissions to Graph ACLs before the first ingest run, not after.

For cloud connectors, the same principle applies to your app registration: rotate secrets on a schedule if you must use them, but prefer certificate-based auth from day one. Client secrets that live in config files or environment variables are a breach waiting to happen in a professional-services environment where staff turnover is real.

PII handling requires deliberate scoping. Minimize what you index in the content field. If a source document contains client PII alongside the substantive content Copilot needs, pre-process the content before ingestion to strip or anonymize the PII. Apply Microsoft Purview sensitivity labels to the externalConnection where your data classification policy requires it. Purview integrates with connector workflows to enforce retention and labeling policies on indexed content.

Data residency is a concern for firms with international clients or cross-border data obligations. Synced connectors copy data into Microsoft Graph, which stores it in the tenant’s data residency region. Confirm your Microsoft 365 tenant’s data residency configuration before indexing content subject to GDPR, state privacy laws, or client contractual restrictions. When data residency is a hard constraint, federated connectors are the correct architectural choice — the data never leaves its source.

For a governance review checklist before ingestion: confirm data classification, verify ACL mapping, obtain legal sign-off on what can be indexed, document the data flow for your compliance register, and set a retention policy for the externalConnection.

How do you validate, monitor, and maintain connectors in production?

A connector that passes initial testing can still degrade quietly. Sync failures, ACL drift, and schema mismatches accumulate over time if you are not watching the right signals.

Validation checklist for PoC

Run these checks before declaring a PoC complete:

  • Query Copilot with five representative questions your staff actually ask. Confirm indexed items appear as citations.
  • Verify urlToItemResolver by sharing a source URL in a Teams chat and confirming Copilot recognizes and surfaces the corresponding indexed item.
  • Test ACL trimming: log in as a user who should NOT have access to a specific item and confirm it does not appear in their Copilot results.
  • Check ingestion error logs in the Microsoft 365 admin center under Search & Intelligence. Any items with ingestion errors are invisible to Copilot.

Telemetry and monitoring

For Copilot telemetry, track index health (item count vs. expected count), sync latency (time from source update to index update), ingestion error rate, and — for federated connectors — query latency per request. In Copilot itself, track citation frequency: how often does Copilot cite your connector’s content in responses? A low citation rate despite a healthy index usually points to a schema or urlToItemResolver problem.

Set alerts on ingestion error rate thresholds and on sync jobs that have not completed within their expected window. The connector agent logs are the first place to look for on-premises sync failures; check them before escalating to Microsoft support.

Schema updates and versioning

Schema changes in production require care. Adding a new property to an existing schema is generally safe and triggers an incremental re-index. Changing a property type or removing a property requires deleting and recreating the externalConnection, which means a full re-ingest. Plan schema changes during low-usage windows and maintain a staging externalConnection for testing schema updates before applying them to production.

For version control, treat your connector code and schema definition as you would any production application: source control in Git, change review process, and a documented rollback procedure.

Gozera’s implementation checklist for your first connector PoC

This is the rollout template Gozera uses with mid-market professional-services clients. It is scoped for a 4–8 week PoC that produces a measurable result, not a proof of technology.

  1. Week 1: Source selection and data classification. Identify the top three questions staff ask that Copilot currently cannot answer. Map each to a data source. Run data classification on each source to determine connector model (synced vs. federated) and governance requirements.

  2. Week 2: Schema design and app registration. Define the externalItem schema for your chosen source. Map source fields to Graph properties, apply semantic labels, and plan the ACL mapping. Register the Azure AD app and obtain admin consent.

  3. Week 3: Ingestion pipeline build. Implement the ingestion code using the Copilot connectors SDK. Run a small-batch test ingest (100–500 items). Validate schema, ACLs, and urlToItemResolver in a non-production connection.

  4. Week 4: Full ingest and validation. Run the full ingest. Execute the validation checklist above. Fix any schema or ACL issues before user testing.

  5. Weeks 5–6: User testing and telemetry baseline. Enable the connector for a pilot group (10–20 users). Collect baseline telemetry: time-to-answer for target queries, citation frequency, and user-reported confidence in Copilot responses. For Copilot workflow integration, map connector outputs to specific billable tasks.

  6. Weeks 7–8: ROI measurement and production decision. Measure time-to-answer improvement against baseline. Estimate recoverable billable hours based on time saved per query type and query frequency. Calculate license utilization uplift. Present findings to stakeholders and make the go/no-go decision for production deployment.

ROI metrics to track during PoC:

  • Time-to-answer improvement for target query types (before vs. after connector)
  • Citation-driven task completion rate (did Copilot’s answer include a connector citation that led to task completion?)
  • Recoverable billable hours per week (time saved × billing rate × query frequency)
  • Copilot license utilization rate (active users / licensed users, measured via telemetry)

Pro Tip: Pick your first connector target based on query frequency and billable impact, not data volume. A connector that answers 50 high-value queries per day for a team of 10 attorneys delivers more measurable ROI than one that indexes 500,000 documents nobody searches for. Start small, measure fast, and expand.

For production deployment, the checklist adds: governance sign-off documentation, agent hardening (certificate auth, network firewall rules), SLA definition for sync frequency, telemetry baseline established, and runbooks written for the operations team. Schedule month-1 and month-3 ROI check-ins against the PoC baseline. The Microsoft 365 Copilot implementation guide covers the broader governance and deployment framework if you need it alongside the connector-specific steps.

Key Takeaways

Graph connectors for Copilot deliver measurable ROI only when the connector model matches the data’s governance requirements, the schema is designed for semantic retrieval, and ACLs mirror source permissions exactly.

Point Details
Choose the right model first Use synced connectors for searchable knowledge repos; use federated for regulated or live data that cannot be indexed.
Schema and ACLs are non-negotiable Missing urlToItemResolver and misconfigured ACLs are the two most common reasons indexed content stays invisible or leaks to wrong users.
Start narrow in your PoC Target one high-frequency data object type; measure time-to-answer and recoverable billable hours before expanding scope.
Prebuilt connectors save weeks Check the connector gallery first — SharePoint, ServiceNow, Salesforce, Jira, and Azure DevOps are available prebuilt and cut PoC time significantly.
Gozera accelerates PoC delivery Gozera’s fixed-price PoC sprints include schema design, connector build, agent installation, telemetry setup, and ROI measurement for mid-market professional-services firms.

The part most teams get wrong about connector projects

The technical implementation of a Copilot connector is genuinely not that hard. Microsoft’s SDK is well-documented, the Graph API is consistent, and the prebuilt connector gallery covers most common enterprise sources. What trips teams is everything that happens before and after the code.

Schema decisions made in week two become expensive constraints in week eight. I have seen firms ingest 200,000 documents with a schema that omitted semantic labels on the title field, then wonder why Copilot was not citing their content. The fix required a full re-ingest. That is a week of work that a 30-minute schema review would have prevented.

The governance gap is just as common. A team gets excited about indexing client matter files, builds the connector, and then discovers in week six that legal has concerns about what is being indexed and who can see it. The PoC stalls for a compliance review that should have happened in week one. Bring legal and compliance into the scoping conversation before writing any code.

The organizational challenge underneath all of this is that connector projects require cross-functional sponsorship. IT builds the connector. Legal approves what gets indexed. Operations defines the target queries. The managing partner signs off on the ROI case. When any one of those stakeholders is not engaged from the start, the project either stalls or delivers a technically correct connector that nobody uses.

The firms that get this right treat the connector project as a workflow reengineering initiative with a technical component, not a technical project with a workflow component. That framing changes who is in the room, what gets prioritized, and how success is measured. Telemetry-driven KPIs — citation frequency, time-to-answer, recoverable billable hours — keep the conversation grounded in outcomes rather than features.

Gozera’s Copilot connector services: PoC to production

Mid-market professional-services firms that have tried to run connector projects internally often hit the same wall: the technical work is manageable, but the combination of schema design, governance review, agent configuration, and ROI measurement is more than an already-stretched IT team can absorb alongside their day job.

Gozera

Gozera runs fixed-price connector PoC sprints that cover the full stack: source selection and data classification, schema and semantic label design, connector build using the Microsoft Graph SDK, agent installation for on-premises sources, ACL mapping and governance review, telemetry setup, and a documented ROI measurement report at the end of the engagement. The typical engagement runs 6–8 weeks and delivers a production-ready connector with a measurable baseline for time-to-answer improvement and license utilization uplift. There are no open-ended retainers required to start — the PoC is a fixed scope with a defined output.

If your Copilot licenses are sitting idle because the out-of-the-box experience does not reach your firm’s actual knowledge, a connector PoC is the fastest path to changing that. Request a Copilot connector assessment and Gozera will scope a PoC against your highest-value data source within one week.

The resources below are the canonical references for planning and executing a Copilot connector implementation:

Save these links to your implementation ticket before your first sprint planning session. The SDK samples and the connector agent docs are the two you will return to most often during build.

← Back to all articles

© 2026 Zera Consulting. gozera.ai