workspaces
1541 TopicsWorkspace IP Firewall: Expected Behavior for Cross-Workspace API Calls?
We are evaluating Workspace IP firewall rules and noticed that cross-workspace API calls may be blocked when the source IP is not included in the workspace allowlist. Example: Workspace A uses its Workspace Identity to call Fabric APIs. Workspace B is protected by Workspace IP firewall rules. Workspace A has the required permissions on Workspace B. The API call fails because the source IP is not allowed. Is this expected behavior? If so, what is the recommended approach for secure Fabric-to-Fabric API communication between workspaces protected by Workspace IP firewall rules? More specifically, are Workspace Identities and Service Principals expected to work in this scenario, or are they also subject to the same IP-based restrictions? Workspace IP firewall rules restrict incoming access based on approved IP addresses. Additionally, is Microsoft currently evaluating any enhancements in this area, such as support for trusted Workspace Identities or Service Principals for cross-workspace API scenarios?Solved159Views1like4CommentsFabric 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-availability59Views0likes3CommentsArchitectural 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!46Views0likes3CommentsBest 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.22Views0likes2CommentsFabric Data Agent visualization through MCP
I'm testing the new Fabric Data Agent visualization capability in the September 2026 update. In the native Fabric Data Agent experience, a question can return an interactive chart successfully. I'm consuming the same published Data Agent through its MCP endpoint from an external Next.js application. The MCP response gives me the answer/data, but I don't see the visualization specification needed for the external client to reproduce the chart. What is the supported way for an external MCP client to retrieve the visualization specification generated by the Data Agent and is this specification currently exposed through the MCP response/assistant run steps, or is visualization rendering currently limited to the native Data Agent experience?28Views0likes3CommentsDP-600 voucher
Hello, I hope everyone is doing well! I would like to know if there are any community events happening that offer a 100% discount voucher for the DP-600 certification. Besides the upcoming Microsoft Certification Week, are there any other events, communities, or initiatives currently offering this type of voucher soon? If anyone knows of any opportunity, I would really appreciate it if you could share it. 🙂45Views1like3CommentsDP-600 Voucher
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } Hi everyone, I recently passed the DP-700 Microsoft Fabric Data Engineer Associate certification and am now planning to take DP-600 (Microsoft Certified: Fabric Analytics Engineer Associate) while the Fabric concepts are still fresh in my mind. Unfortunately, I wasn't able to use a previous DP-600 voucher when I first received it as I wasn't ready for the exam at the time. I was wondering if anyone is aware of any current voucher opportunities for DP-600, or has an unused voucher that they won't be using and is transferable (if permitted by the voucher terms). Any guidance would be greatly appreciated. Thanks in advance! Regards, Amanul13Views0likes1CommentSPN gets 401 'not authenticated' on all Fabric REST APIs despite correct tenant setting & group
Setting up service principal auth for Fabric Data Agent MCP, following the official docs. Getting 401 even on the most basic APIs, before touching the Data Agent itself. Confirmed correct: Token acquired fine via ClientSecretCredential, scope https://api.fabric.microsoft.com/.default JWT decoded — aud, appid, tid, idtyp: app all correct Tenant setting "Service principals can call Fabric public APIs" enabled + SPN in scoped security group SPN has Contributor on workspace + Read on the semantic model Error (same on /v1/workspaces and /v1/capacities, not workspace-specific): HTTP 401 {"errorCode":"Unauthorized","message":"The caller is not authenticated to access this resource"} Request ID: d8cb8a65-6276-4629-a966-37a059198c3f What should I actually try next to fix this , is there a specific setting/step I'm missing? Thanks in advance!56Views0likes4CommentsPlanning sheets show "No rows to display" with model measures since 30 Sep update
Since 30 Sep update, Fabric Planning sheets go blank with any model measure. Column sums still work. Symptoms All saved Planning sheets open as "No rows to display". Sync reports "Successfully fetched data and catalog details", but the grid stays empty. When I add any explicit semantic model measure to Values, the grid freezes: no value column appears and later changes aren't reflected. After saving and reopening, the sheet shows "No rows to display". Implicit column aggregations work, both "Sum of <column>" and data inputs. A sheet built only from these saves, reloads and writes back normally. It reproduces in a brand-new Plan item connected to the same model, with a long-standing measure (a simple Budget measure). What we've ruled out The model: An XMLA trace shows the Plan's grid query (SUMMARIZECOLUMNS with the measures and their [_<measure> FormatString] references) succeeding with no errors. Re-running the exact query returns the expected rows (79 rows in one case). Reports on the same model render normally. Connections: The App Database connection works. The Direct Lake sources are mapped to fixed-credential OAuth connections, not SSO. Model changes: measures and calculation groups are unchanged, and format strings are normal. Filters: none Environment Semantic model in Direct Lake mode on OneLake, plus calculated tables. Planning writeback to a Fabric SQL database. Australia East region. Questions Is anyone else seeing Planning sheets fail to display semantic model measures since this update? Is this a known issue, and is a fix or rollback planned?23Views0likes1Comment