Microsoft has quietly opened a door that a lot of Power Platform and Fabric teams have been waiting for: you can now connect a Fabric data agent directly into a custom Copilot Studio agent as a connected agent. This is still a preview capability, but it changes the shape of what “grounding in enterprise data” actually means for makers building agents in Copilot Studio.

Here is what it is, why it matters, and what your governance team needs to lock down before anyone flips it on.

What is actually new here

Fabric data agents let you point an AI agent at a warehouse, lakehouse, Power BI semantic model, KQL database, mirrored database, or ontology, and have it answer natural language questions grounded in that data. Until now, using one of those agents inside a broader Copilot Studio experience meant extra plumbing.

With this update, a Fabric data agent can be added to a custom AI agent in Copilot Studio the same way you would add any connected agent. The custom agent can call out to the Fabric data agent, pull grounded answers from enterprise data, and fold that into its own response. This is agent to agent collaboration, not a one-off connector call. Copilot Studio’s orchestration layer decides when to invoke the Fabric agent based on the conversation, the same way it would decide to invoke any other tool or connected agent.

For makers, that means you can build one Copilot Studio agent that blends SharePoint knowledge, custom tools, and live enterprise data answers from Fabric, all in a single conversational surface deployed to Teams.

The governance detail that should not get skipped

Buried in the prerequisites is a compliance point that deserves its own paragraph rather than a footnote. When you configure a Fabric data agent to be consumed inside Copilot Studio, the responses returned by that data agent can leave Fabric’s compliance boundary and geographic region. Once that happens, the data is processed and stored under Copilot Studio’s own terms and data handling policies, not Fabric’s.

That is a meaningful shift for any organization with data residency requirements or a Fabric tenant setting that restricts cross-geo processing. Before a single maker touches this feature, admins need to review and knowingly enable cross-geo processing and cross-geo storing for AI at the tenant level. If your organization has that setting locked down for a reason, this feature will not work at all until someone makes a deliberate, documented decision to open it.

Verification flag: cross-geo processing and storing behavior for AI in Fabric tenant settings should be confirmed against your current tenant configuration before rollout, since these settings and their defaults are the kind of thing Microsoft revises during preview.

What needs to be true before you start

A few prerequisites gate this feature, and they span licensing, tenancy, and permissions:

Licensing and capacity

• A paid F2 or higher Fabric capacity, or Power BI Premium per capacity (P1 or higher) with Microsoft Fabric enabled
• A Microsoft 365 Copilot license, plus a user license for each person who builds and manages custom agents

Data and tenancy

• At least one data source with actual data in it: a warehouse, lakehouse, Power BI semantic model, KQL database, mirrored database, or ontology, with read access
• The Fabric data agent and the Copilot Studio agent must live on the same tenant
• Both Fabric and Copilot Studio must be accessed with the same account that has access to the data agent

Permissions

• At least read access to the Fabric data agent
• Permission to create and modify agents in Copilot Studio
• Access to the underlying data sources the data agent draws from

The data agent itself also has to be publish ready. That means it is responding to queries correctly and has been published with a rich, detailed description, since that description is what helps the Copilot Studio orchestrator decide when to call it.

How the connection actually gets built

Once the prerequisites are in place, the flow inside Copilot Studio looks like this:

1. Open Copilot Studio and select the environment, then create a new custom agent, or open an existing one
2. Give the agent a name and description, and add whatever knowledge sources and tools it needs
3. Go to the Agents tab and select Add, then choose Microsoft Fabric as the extension category
4. Create or select the connection between Fabric and Copilot Studio, if one does not already exist
5. Select the specific Fabric data agent from the list of ones you have access to, adjust its description if needed, and add it
6. Decide on authentication for the connected agent, either user authentication or agent author authentication. If you choose user authentication, every end user needs their own access to the Fabric data agent and its underlying data
7. Turn on generative AI orchestration in the agent’s settings, since that is what allows the custom agent to reason about when to invoke the connected Fabric agent
8. Test in the built in chat pane to confirm the custom agent is actually invoking the Fabric data agent rather than answering from its own knowledge
9. Publish, then choose your channel

One channel restriction that matters for planning

This is the detail most likely to derail a rollout plan: a custom Copilot Studio agent with a connected Fabric data agent is only formally validated for Microsoft Teams. It is explicitly not currently supported in Microsoft 365 Copilot, and while other channels may technically work, they have not been tested by Microsoft.

If your roadmap assumed this would light up inside Microsoft 365 Copilot alongside Teams, adjust that expectation now. Build and test for Teams first, and treat any other channel as unvalidated until Microsoft says otherwise.

Why this matters for governance-minded Power Platform teams

This feature quietly raises the stakes on a few things governance teams already care about:

Data agent descriptions are now a routing mechanism, not documentation. A vague or thin description on a Fabric data agent will lead to a Copilot Studio orchestrator that either never calls it or calls it at the wrong moments. Treat the publish step for a data agent as seriously as you would treat an API contract.

Authentication choice is a real access control decision. User authentication versus agent author authentication changes who is effectively querying enterprise data through the custom agent. That choice belongs in your agent governance review, not left to whoever happened to build the connection.

Cross-geo and compliance boundary settings need an owner. This is a tenant-level setting with real regulatory weight, and it should not be toggled on by a maker trying to unblock their own project.

The bottom line

Connecting a Fabric data agent into Copilot Studio turns a data agent from a Fabric-only conversational tool into a component that any custom agent across your organization can call on. That is genuinely useful for building richer, more grounded agents. It also means enterprise data can now cross a compliance boundary it previously stayed inside, gated behind a tenant setting that is easy to miss in the prerequisites list.

Before this rolls out broadly, confirm your cross-geo AI settings, decide on an authentication model deliberately, and start with Teams as your only validated channel.

Verification flags for this article: preview status and channel support (Teams only, validated) should be reconfirmed against the live Microsoft Learn page before publishing, since Microsoft updates preview feature scope frequently. Source last updated 2026-05-12, referenced 2026-07-17.

Source: Microsoft Learn, “Consume a data agent in Microsoft Copilot Studio (preview) – Microsoft Fabric”