Federated Copilot Connectors: Live Intranet Data

Federated Copilot Connectors reached general availability at Build 2026 (May 20-22) after nine months in preview, and they change the shape of what a modern SharePoint intranet can answer. The mechanism is simple: instead of ingesting third-party data into the Microsoft 365 semantic index (the model classic Graph connectors used), federated connectors call the third-party system live at prompt time via MCP. No indexing lag. No duplicate storage. No data residency workarounds.

Our team has deployed federated connectors on three intranet builds since GA. This post covers what has actually worked, how it differs from the classic indexed model, and the three use cases that produce the most user satisfaction on day one.

How federated connectors differ from classic indexed connectors

The classic Microsoft Graph connector model was an ingestion pipeline: you connect to ServiceNow or Salesforce or SAP, you configure what to index, Microsoft crawls it on a schedule, results land in the semantic index, and Copilot searches the index. That model has real strengths — offline search works, latency is predictable, cost is bounded — but it has three chronic pains:

• Freshness lag. Index rebuilds every 15 minutes at best, more often every hour. A ticket that closed 20 minutes ago still shows open.
• Storage duplication. Your ServiceNow data is now also in the Microsoft 365 tenant. Compliance teams noticed.
• Data residency friction. For customers with regulatory constraints, indexing regulated data into Microsoft 365 was a hard no.

Federated connectors solve all three by not indexing at all. When a user prompt matches a federated connector's trigger pattern, Copilot invokes the connector's MCP endpoint at prompt time, the connector calls the underlying system's API live, and the result is returned to the model as tool output. The data never lands in the M365 semantic index.

| Dimension | Classic (indexed) Graph connector | Federated Copilot Connector |

|-----------|-----------------------------------|-----------------------------|

| Data location | Ingested into M365 semantic index | Queried live, never stored |

| Freshness | 15-60 minute lag | Real-time (single-digit-second latency) |

| Offline / cached results | Yes | No |

| Data residency | Copy in M365 tenant | No copy — stays in source system |

| Cost model | Ingestion + storage | Per-invocation |

| Best for | High-volume, low-freshness (product catalog, KB articles) | Low-volume, high-freshness (open tickets, live orders, account status) |

Reference: Federated Copilot Connectors — bringing real-time enterprise data within Microsoft Copilot and the Copilot connectors overview.

The three intranet use cases that produce day-one value

1. Open ServiceNow tickets, surfaced on the intranet homepage

The archetypal use case. User asks Copilot "what tickets do I have open," or the intranet homepage embeds a "My open tickets" widget that calls the federated ServiceNow connector on page load. The connector queries ServiceNow live, returns the current state, and the widget renders. If the user resolves a ticket in ServiceNow and refreshes the intranet page, the resolved ticket disappears — no 30-minute wait for the index to catch up.

Configuration: federated ServiceNow connector, scoped to the current user's incidents. Latency budget: 800ms-1.8s per call.

2. SAP purchase-order lookup from a document conversation

A user is reviewing a proposal document in SharePoint and asks Copilot "what is the status of PO number 44012088." The federated SAP connector triggers on the PO number pattern, calls SAP's OData endpoint live, and returns the current status, expected delivery, and outstanding balance. The document context and the ERP context stay in the same conversation.

Configuration: federated SAP connector, PO lookup scope only (do not open broader access). Latency budget: 1.5s-3s per call.

3. Salesforce account status inside the account team's SharePoint site

Each key-account SharePoint site has an embedded widget: "Current account health from Salesforce." The widget calls the federated Salesforce connector on page load and returns the live opportunity list, recent case history, and account owner. When a rep updates the opportunity in Salesforce, the SharePoint widget reflects it on next refresh.

Configuration: federated Salesforce connector, per-user identity (each user sees only what they can see in Salesforce). Latency budget: 700ms-2s per call.

Common thread: live-state, small-payload, user-scoped questions. That is where federated connectors dominate the classic indexed model.

Setup steps

Federated connector setup follows the same admin pattern regardless of source system:

• Register the connector in the Microsoft 365 admin center — Copilot connectors section, "Add federated connector."
• Provide the MCP endpoint URL. For first-party ISV connectors (ServiceNow, SAP, Salesforce, Workday) the URL is preconfigured. For custom connectors you host the MCP server yourself.
• Configure the identity model. The two options are (a) per-user delegated identity — each user's calls run under their own credentials in the source system, and (b) service-account identity — all calls run under one identity with results filtered by user context. Per-user is stronger for security; service-account is stronger for consistent performance. Pick per-user unless there is a hard reason not to.
• Set the trigger patterns. What prompts should trigger this connector? Federated connectors are opted-in per-prompt via pattern matching — a Salesforce connector triggers on prompts mentioning accounts, opportunities, or cases, but not on generic questions.
• Configure the sensitivity-label posture. Federated connectors respect Agent 365 sensitivity-label ceilings applied to the invoking Copilot's agent identity.
• Roll out to a pilot audience. Do not enable tenant-wide on day one. Pilot with the team that owns the connected system so bad configurations surface in a friendly audience.

Latency budget realism

The freshness advantage costs you latency. Every federated connector call adds real time to the response:

• Best case: 500-800ms for a warm ISV connector with a single API call.
• Typical: 1-2 seconds for a query with a couple of joins in the source system.
• Worst case: 3-5 seconds for a slow ERP with a cold cache.

If a Copilot prompt triggers three federated connectors in parallel, the total response latency is roughly the slowest one plus 200-400ms of coordination overhead. In practice, budget 2-4 seconds of additional response time for federated-heavy prompts. This is a real UX cost — worth it for the freshness gains, but users notice.

Permissions inheritance model

This is where teams get burned. Federated connectors do NOT automatically inherit SharePoint permissions. The permissions model runs in three layers:

• Can this Copilot instance invoke this federated connector at all? Controlled by the Copilot license and the connector's admin-configured audience.
• Under what identity does the connector call the source system? Per-user delegated or service-account.
• What can that identity see in the source system? Governed entirely by the source system's ACLs — Salesforce sharing rules, ServiceNow ACLs, SAP authorization objects.

The consequence: if you have a user who cannot access a SharePoint site but can access a Salesforce account, the federated connector will happily return the Salesforce data even if the prompt was issued from that SharePoint site. That is not a bug — it is the federated model working as designed. If you want to constrain federated calls to SharePoint-permissioned contexts, you have to enforce that in the connector's trigger scope, not in the SharePoint site.

Related intranet architecture

• SharePoint intranets — the broader architecture that federated connectors slot into.
• SharePoint Copilot — Copilot rollout planning that includes federated connectors.
• SharePoint document management — where indexed connectors are still the better choice.

Expert help from our SharePoint consultants

Federated Copilot Connectors are the fastest way we have found to make a SharePoint intranet feel "live" in 2026 — the freshness upgrade over classic indexed connectors is dramatic and users notice on day one. Our SharePoint consultants design and deploy the connector portfolio, wire the permissions correctly, and set the latency budget so the UX stays crisp. If ERP or CRM freshness is a chronic complaint on your intranet, reach out and we will scope a pilot.