Fabric Data Agent ViZ How can external MCP access Viz
I'm testing the new Fabric Data Agent visualizations capability released in the September 2026 updates.I have a Fabric Data Agent connected to a Power BI semantic model and can successfully ask: Questions, and in the native Fabric Data Agent experience, the agent correctly returns an interactive line chart. I'm now consuming the same published Data Agent through its MCP endpoint from a custom Next.js application. The MCP tool currently returns a text content block containing the answer/data, but no structuredContent. I noticed the current Microsoft documentation says "The underlying visualization specification (chart type, axes, and aggregated data) is emitted in the assistant run's steps, so a client can reconstruct the chart from that specification." My question is: What is the supported way for an external MCP client to retrieve these assistant run steps / visualization specifications? Specifically: Is the visualization specification currently exposed through the Fabric Data Agent MCP endpoint?If so, is it returned through the new MCP Tasks mechanism? Is there a documented schema/example showing the visualization specification returned for a line/bar chart? Is this capability already available through the current MCP endpoint, or is support for external clients still being rolled out? Any guidance or sample response would be greatly appreciated.
Cannot log ticket on Since 30 Sep update, Fabric Planning sheets go blank with any model measure.
Cannot log ticket on Since 30 Sep update, Fabric Planning sheets go blank with any model measure. Column sums still work. Planning sheets blank ("No rows to display") when using semantic model measures. Started after the 30 Sept service update.
Best Implementation Practices
Hi experts, I have recently join a Fabric greenfield project,my previous experience has been building up data lake ,delta lake and datalakehouse. The client has smaller user base of less than 100 users, and mainly API based ingestions,might be some other sources involved. First , we have to choose between OneLake , Data Lake or go for open source database Postgres. I recommended OneLake primarily because of fitment of the solution cost and other aspects. I now go forward with building other components or building blocks such as workspace topology or methodology . I would request the experts to please share the what are the critical factors I should be taking into account moving ahead. What are pitfalls or grey areas I should be cautious about . Any links or blogs that would help me along would be great help. Thank youFabric App availability in UK South
The Fabric region availability link says UK South now has Fabric Apps (it's not listed in the `Unavailable Fabric features` column). However, when I go to my UK South Fabric capacity, where quite a while ago I set "Enable Fabric App Items (preview)" to be "Enabled for the entire organization", Fabric Apps still don't appear in my UK South workspace when I want to add a New Item. Any idea why it's not appeared yet? https://learn.microsoft.com/en-us/fabric/admin/region-availability
Possible regression in OneLake File Explorer 1.1.1.0 with B2B Guest cross-tenant access
Hi Fabric Community, I am seeing what appears to be a regression in OneLake File Explorer 1.1.1.0 when accessing Fabric resources as an Entra ID B2B Guest in another tenant. Scenario My enterprise account belongs to my corporate tenant and is configured as a B2B Guest in a customer's tenant. The same account can: switch to the customer tenant in the Fabric web portal; access the expected customer workspaces; successfully authenticate directly against the customer tenant through PowerShell and Fabric REST APIs. Issue with OneLake File Explorer 1.1.1.0 I sign out and authenticate using: Use another account → Sign-in options → Sign in to an organization → Customer tenant → My enterprise B2B Guest account Authentication succeeds and the OneLake logs show no 401, 403, AADSTS, token refresh, or authorization errors. The client successfully reaches: Auth completed via interactive flow Auth completed via silent flow Fetching artifacts list Starting sync engine Application initialization completed successfully However, Windows File Explorer only shows workspaces from my home corporate tenant. The customer workspaces are missing. Fabric REST validation I explicitly authenticated against the customer tenant: Connect-AzAccount -Tenant "<CUSTOMER_TENANT_ID>" $token = Get-AzAccessToken ` -ResourceUrl "https://api.fabric.microsoft.com" if ($token.Token -is [System.Security.SecureString]) { $accessToken = [System.Net.NetworkCredential]::new("", $token.Token).Password } else { $accessToken = $token.Token } $response = Invoke-RestMethod ` -Method GET ` -Uri "https://api.fabric.microsoft.com/v1/workspaces" ` -Headers @{ Authorization = "Bearer $accessToken" } $response.value | Select-Object id, displayName, type | Sort-Object displayName This correctly returns all customer workspaces I am authorized to access. So the current status is: Entra B2B Guest membership : OK Customer tenant login : OK Fabric permissions : OK Fabric REST API : OK OneLake 1.1.1.0 : Wrong tenant workspace enumeration A/B test I then downgraded OneLake File Explorer from: 1.1.1.0 to: 1.1.0.0 and repeated exactly the same B2B authentication flow. Result: OneLake File Explorer 1.1.0.0 → Customer workspaces visible → WORKING OneLake File Explorer 1.1.1.0 → Only home-tenant workspaces visible → NOT WORKING No Fabric permissions, Entra configuration, or tenant settings were changed between the two tests. Current workaround Downgrading temporarily to OneLake File Explorer 1.1.0.0 restores B2B cross-tenant workspace navigation through Windows File Explorer. I understand that only the latest version is officially supported, so I consider this a temporary workaround and diagnostic evidence. Question Can Microsoft confirm whether OneLake File Explorer 1.1.1.0 introduced changes related to: B2B Guest authentication; MSAL account/tenant selection; tenant resolution; cross-tenant workspace enumeration; MultiCloud authentication? The A/B test strongly suggests that 1.1.1.0 authenticates successfully but enumerates Fabric artifacts from the home tenant instead of the explicitly selected B2B customer tenant. Is this a known issue or regression? Thanks.Git Sync Fails for Fabric Warehouse with Interdependent Views - How to Handle Deployment Order?
Hi Everyone, We are using Git integration in Microsoft Fabric and have encountered an issue while syncing a Git branch to a Fabric workspace. Our workspace contains a Fabric Warehouse with a large number of SQL views. Many of these views are dependent on other views, creating multiple levels of dependencies. For example: View_C depends on View_B View_B depends on View_A View_A depends on base tables During "Update from Git", the Warehouse sync fails because some views appear to be validated or deployed before their dependent views exist. As a result, the entire sync operation fails. Has anyone faced a similar issue with Warehouses containing many interconnected views? I would appreciate guidance on the following: Does Fabric Git integration support automatic dependency resolution for Warehouse views? Is there a way to control the deployment order of Warehouse objects during Git sync? What are the recommended best practices for managing hundreds of interdependent views in source control? Do you maintain separate deployment scripts or pipelines to recreate views in the correct sequence? Is this a known limitation of Fabric Git integration? Any suggestions or workarounds would be greatly appreciated.
Best practices for pipeline orchestration structure in Microsoft Fabric
Hi Fabric Community, We are designing Microsoft Fabric Data Factory pipelines to process Salesforce and Marketo data using a Bronze → Silver → Gold medallion architecture. We are considering creating child pipelines for each object/process and invoking them from parent orchestration pipelines using "Invoke Pipeline". The main responsibilities of each layer are: Bronze: Extract data from Salesforce and Marketo by object and store it in a Lakehouse. Silver: Perform relatively simple transformations on the Bronze data, such as removing unnecessary columns, adjusting data types, adding technical columns, and deduplication. Gold: After the required Silver tables have been successfully updated, combine Salesforce and Marketo data and prepare datasets for an AI agent. The target objects include Lead, Account, Contact, etc. from Salesforce, and Leads, Activities, Activity Types, Programs, etc. from Marketo. Bronze, Silver, and Gold are expected to run on essentially the same refresh schedule. We are currently considering the following four orchestration patterns. Option 1: Use an intermediate orchestration pipeline for Bronze and Silver End-to-End Orchestration ├─ Bronze-to-Silver Orchestration │ ├─ Bronze pipelines by object │ └─ Silver pipelines by object └─ Gold Pipeline Option 2: Invoke each pipeline directly from the end-to-end orchestration pipeline End-to-End Orchestration ├─ Bronze pipelines by object ├─ Silver pipelines by object └─ Gold Pipeline Option 3: Create intermediate orchestration pipelines by source system End-to-End Orchestration ├─ Salesforce Orchestration │ ├─ Salesforce Bronze pipelines │ └─ Salesforce Silver pipelines ├─ Marketo Orchestration │ ├─ Marketo Bronze pipelines │ └─ Marketo Silver pipelines └─ Gold Pipeline Option 4: Create intermediate orchestration pipelines by medallion layer End-to-End Orchestration ├─ Bronze Orchestration │ └─ Bronze pipelines by object ├─ Silver Orchestration │ └─ Silver pipelines by object └─ Gold Orchestration └─ Gold Pipeline The main reasons for separating pipelines by object are to make it easier to rerun only failed processes, monitor individual processing units, and limit the impact of future changes. I would appreciate your advice on the following three points: For this type of workload, which orchestration structure would be considered the most common or closest to best practice in Microsoft Fabric? In particular, if the Silver transformations are relatively simple and all layers run on approximately the same schedule, is there still a meaningful benefit to introducing intermediate orchestration pipelines? How does adding intermediate orchestration layers affect monitoring, maintainability, and CU consumption? I assume that adding intermediate pipelines and additional Invoke Pipeline activities increases CU consumption to some extent. In practice, is this difference significant enough to consider when choosing the orchestration structure? What parent/child pipeline structure is recommended when we want to easily rerun only a specific source, object, or failed process? We expect the number of objects and data sources to increase in the future, so we would like to consider not only the simplicity of the initial implementation but also long-term maintainability and scalability. If anyone is running a similar architecture in Microsoft Fabric, I would also appreciate hearing about the orchestration pattern you use in practice and the factors that influenced your design. Thank you in advance for your advice.
Capacity Metrics User column shows generic values, not user@domain
Hi all, I'm reviewing operation logs (Warehouse Query operations) in Dashboard Fabric Capacity Metrics, and when I filter by the User column, I only see generic values like System, User, and (Blanks), instead of the actual user identities (e.g. [email protected]) who ran the operations. I already have the "Show user data in the Fabric Capacity Metrics app and reports" setting turned ON at the tenant/org level (screenshot attached), so I expected the User column to display actual email addresses instead of just the generic "User"/"System" labels. My questions: Is this expected behavior, or does it indicate a misconfiguration somewhere? We have 2 capacities: one in Southeast Asia and one in Indonesia Central (IDC). Interestingly, only the IDC region shows the actual user value, while the Southeast Asia region still shows the generic placeholder instead of the actual value (e.g., [email protected]). Is this a known issue specific to the IDC region? Is there an additional setting, permission, or propagation delay needed before actual user identities show up instead of the generic "User"/"System" labels? Any guidance would be appreciated. Thanks!
Architectural Advice: Isolating Client Reporting vs. ETL Workloads on F64 Capacity
Hello Fabric Community, We currently run both high-concurrency Client Portal Reports and Heavy ETL/Analytics (PySpark pipelines, lakehouse refreshes, ad-hoc queries) on a single F64 Capacity, leading to resource contention. Proposed Strategy: Separate Capacities: Split into two dedicated capacities—one strictly for user-facing client reporting and one for backend ETL/analytics. (Bonuse stratgey - not a primary focus )Database Mirroring: Mirror source databases directly into our Medallion Lakehouse to reduce pipeline batch ingestion load. Questions: Is splitting an F64 into two separate capacities the recommended way to protect client-facing reporting, or is workspace governance enough? What are the trade-offs regarding CU efficiency and cross-capacity OneLake shortcuts? Has database mirroring proven more CU-efficient than standard metadata-driven copy pipelines? Thanks for your insights!
