A Fabric Data Agent can be configured correctly and still fail at runtime because its workspace capacity and a required data source workspace capacity are in different regions. Enabling a cross-geo AI setting does not remove that source-query restriction. It controls where AI processing or storage may occur; it does not make arbitrary cross-region Fabric data access valid.
Microsoft currently requires a paid F2 or higher Fabric capacity, or P1 or higher Power BI Premium capacity with Fabric enabled, plus the relevant tenant settings. For capacities outside the EU Data Boundary and the United States, Microsoft documents additional cross-geo processing and storage requirements. The deployment therefore needs one reconciled architecture across region, capacity, source, identity, policy, client, and cost.
Can you list the physical capacity region for the agent and every source it must query? If not, pause rollout before a region mismatch becomes a production incident.
Build a deployment map before enabling the agent
Inventory the tenant home region, every Fabric capacity and SKU, workspace assignment, Data Agent workspace, source workspaces, source types, target clients, user groups, administrators, tenant and delegated settings, Purview policies, processing and storage boundaries, billing region, latency objective, disaster-recovery design, and planned migration.
| Architecture element | Required evidence | Failure risk | Deployment control |
|---|---|---|---|
| Agent workspace | Workspace ID, assigned capacity, SKU, physical region, admins, environment, and lifecycle owner. | The agent is created in an incompatible or undersized capacity. | Approved regional placement, capacity headroom, ownership, and release path. |
| Source workspace | Every lakehouse, warehouse, semantic model, KQL database, ontology, and its capacity region. | Queries fail because a source capacity is in a different region. | Same-region placement or an explicitly approved redesign of source and agent boundaries. |
| AI processing | Capacity geography, Azure OpenAI availability, tenant setting, delegated scope, and policy approval. | Feature is unavailable or data is processed outside an expected boundary. | Documented setting, approved geography, affected groups, and validation evidence. |
| AI storage | Prompt, response, and conversation-history storage behavior, geography, retention, and deletion. | Data is retained or located differently than security, privacy, or customer commitments allow. | Approved setting, retention contract, clear-chat behavior, access, and audit. |
| Client path | Fabric, Foundry, Copilot Studio, M365 Copilot, MCP, custom app, identity path, and terms. | Responses leave Fabric's compliance or geographic boundary through another service. | Client-specific data-flow review, terms, permissions, minimization, and user notice. |
| Capacity economics | Input/output tokens, generated source queries, concurrency, other workloads, CU budget, and billing region. | Shared capacity throttles or shuts down operations during peak use. | Load test, budget, alerting, workload isolation, scaling, and rollback. |
Separate source-region compatibility from cross-geo AI settings
Microsoft's same-region source restriction is direct: the Data Agent can't execute queries when a data source workspace capacity is in a different region from the agent workspace capacity. A lakehouse on North Europe capacity and an agent on France Central capacity are Microsoft's example of an invalid pairing.
Cross-geo AI settings solve a different problem. Azure OpenAI models are available in selected data centers, so Microsoft can map processing to another region while treating data residency as a primary constraint and keeping mapping within the same geographic area where possible. Customers are billed using the Fabric pricing in their billing region, even when GPU processing occurs in a mapped consumption region.
Microsoft states that tenant-setting changes can take up to one hour to take effect. Record tenant-level and delegated capacity-level scope, included groups, effective time, and validation result. A screenshot of a switch is not proof that every target user, capacity, and client path works as intended.
Test the real deployment matrix
| Test family | Test | Pass condition | Remediation |
|---|---|---|---|
| Same-region source | Run approved questions against every selected source on the intended capacity. | Generated query executes under each user's effective permissions and matches ground truth. | Workspace reassignment, agent relocation, source redesign, or excluded source. |
| Region mismatch | Prove expected failure for an intentionally incompatible source and capture diagnostics. | Failure is explicit, monitored, documented, and never presented as an empty business result. | Architecture correction and a tested incident runbook. |
| Setting scope | Test enabled, disabled, delegated, included, and excluded groups after propagation time. | Only approved users and capacities can use the feature, with predictable errors elsewhere. | Tenant or capacity setting, group assignment, propagation wait, or policy correction. |
| Data boundary | Trace prompt, source query, response, history, logs, and metadata for each geography and client. | Every processing, storage, and transfer path matches approved policy and customer terms. | Client restriction, data minimization, different region, setting change, or rollout block. |
| Non-Fabric client | Invoke through Foundry, Copilot Studio, M365 Copilot, MCP, or custom app as applicable. | Identity, permissions, data handling, response fidelity, logging, and deletion follow the client contract. | Integration redesign, OBO identity, separate agent, policy, or channel exclusion. |
| Capacity load | Run representative concurrency, token sizes, source queries, and competing Fabric workloads. | Latency, errors, CU use, source cost, and other workloads remain within objectives. | Capacity isolation, scaling, prompt/query optimization, quotas, or staged rollout. |
| Change and recovery | Reassign capacity, change settings, pause or scale, fail a source, and execute rollback in nonproduction. | Owners detect impact, preserve data, restore service, and reconcile behavior within targets. | Migration sequencing, freeze window, backups, rollback automation, or architecture revision. |
Test effective business answers, not only successful connections. Same-region placement can make a query executable while schema selection, permissions, DLP, source instructions, or generated SQL still produce the wrong answer. Regional validation belongs inside the wider Data Agent accuracy and governance suite.
Move workspaces only through an evidence-backed plan
Moving an agent or source to align regions can affect every item and consumer in the workspace. Microsoft documents that workspace reassignment cancels item jobs and that cross-region movement can be blocked by non-movable items. Capacity stability, permissions, source dependencies, semantic model refresh, shortcuts, pipelines, reports, APIs, credentials, schedules, and rollback all need review.
Prefer the smallest architecture change that satisfies source compatibility and data-residency requirements. Options include locating the agent beside authoritative sources, consolidating approved sources into a same-region serving layer, separating agents by region or domain, or retaining a governed non-conversational path for sources that can't move.
Keep source and destination capacities stable during reassignment. Validate inventory before the move, stop or drain jobs deliberately, reconcile item state and permissions afterward, rerun the Data Agent ground-truth suite, and preserve a tested rollback window. Do not discover non-movable items during the production change.
Run a two-to-four-week deployment assessment
- Select the tenant, target regions, Data Agents, capacities, workspaces, sources, clients, user groups, owners, and rollout deadline.
- Inventory home region, physical capacity regions, SKUs, assignments, source dependencies, settings, delegated scopes, policies, identities, clients, and current failures.
- Create the approved region and data-flow architecture with same-region source rules, AI processing and storage boundaries, client paths, capacity budget, and residual risks.
- Test same-region queries, intentional mismatches, setting propagation and group scope, non-Fabric clients, permissions, policies, load, failure, and recovery.
- Design any workspace or source migration with item compatibility, job cancellation, dependency, data, security, schedule, validation, and rollback controls.
- Reconcile generated queries and answers after the architecture change; compare latency, CU use, source cost, and competing workload impact.
- Deliver the region map, settings matrix, data-flow record, test evidence, migration plan, capacity forecast, runbooks, release gates, and go, limit, redesign, or stop recommendation.
Frequently asked questions
Can a Fabric Data Agent query a data source in a different capacity region?
No. Microsoft currently states that a Fabric Data Agent can't execute queries when the data source workspace capacity is in a different region from the Data Agent workspace capacity. Place the agent and every required source on compatible same-region capacities or redesign the deployment.
What capacity does Fabric Data Agent require?
Microsoft currently lists a paid Fabric F2 or higher capacity, or a Power BI Premium per capacity P1 or higher capacity with Fabric enabled, as a prerequisite. The correct production size still depends on agent token use, generated source queries, concurrency, other workloads, and operational headroom.
When are Fabric Data Agent cross-geo AI settings required?
Microsoft documents cross-geo processing and storage settings for customers whose Fabric capacity geography is outside the EU Data Boundary and the United States. Exact requirements depend on capacity location, tenant and delegated capacity settings, feature path, and current Microsoft guidance.
Can non-Fabric clients change the Data Agent data-handling boundary?
Yes. Microsoft warns that when a Fabric Data Agent is consumed through services such as Microsoft Foundry, Copilot Studio, Microsoft 365 Copilot, or an MCP server, returned responses may leave Fabric's compliance boundary or geographic region and follow the connected service's terms and data-handling policies.
How long does a Fabric Data Agent cross-region deployment assessment take?
A focused assessment commonly takes two to four weeks for one tenant, a defined set of capacities, workspaces, sources, clients, and target regions. It covers region mapping, tenant settings, data residency, source compatibility, permissions, capacity, migration constraints, validation, rollout, and rollback.
Official implementation references
- Fabric Data Agent prerequisites and same-region source limitation
- Fabric Data Agent cross-geo tenant settings and non-Fabric service warning
- Fabric Data Agent CU consumption, region mapping, and billing
- Find the Fabric tenant home region
- Fabric workspace capacity reassignment restrictions and migration issues
Start with the source the agent must query but whose workspace capacity region nobody has verified. Datrick can map the deployment, validate every setting and client path, test capacity behavior, and design a controlled regional migration when required.