How to get a Custom JSON Response Instead of the Default DataFrame Format from a Fabric ML Endpoint?
Hi , I'm currently exploring Fabric ML Model Endpoints. The endpoint currently returns predictions in a DataFrame-oriented JSON structure, similar to: { "formatType": "dataframe", "orientation": "values", "predictions": [ [ 0.92, "Category A" ] ] } However, I would like the endpoint to return a JSON response with named fields, such as: { "predictions": [ { "probability": 0.92, "category": "Category A" } ] } I understand that the model's output can be modified, but the REST API appears to use a predefined response structure. I wanted to clarify: Is there any supported way to customize the HTTP response structure directly from a Fabric ML Model Endpoint? Can the formatType or orientation parameters be configured to return named JSON objects instead of positional arrays? Would modifying the model's predict() output or MLflow signature affect the HTTP response format? Is there any Fabric-native alternative to achieve this without introducing an external API layer? I'm particularly interested in whether this is supported natively within Fabric, rather than transforming the response in the consuming application. Any guidance, documentation, or recommended approaches would be appreciated. Thanks!Fabric ML Model Endpoint returns 401 from application but works in Postman with the same token
Hi , Now, I'm currently integrating the Fabric ML Model endpoint with a .NET application and encountering a 401 Unauthorized error when calling the scoring API. The endpoint is activated and working as expected when tested directly through Postman. However, when the application calls the same Fabric scoring API, it returns HTTP 401. As far as we've verified, the same Bearer token and authentication details are being used. Endpoint pattern: POST /v1/workspaces/{workspaceId}/mlmodels/{modelId}/endpoint/score Error response: { "errorCode": "RequestFailed", "message": "Unable to process the request", "isRetriable": false } Additional details from the application logs: HTTP status: 401 Unauthorized Authorization header present on final request: True WWW-Authenticate header: Empty Postman request: Successful Application request: Fails with 401 The error response doesn't provide any additional information to identify the exact cause. I'm trying to understand whether there are any specific authentication, authorization, endpoint configuration, or HTTP client requirements when calling Fabric ML Model endpoints from an external application. Has anyone encountered a similar issue where the same token works in Postman but fails when used in the application? Are there any additional headers, permissions, redirect behaviors, or diagnostic steps that we should check to identify the cause? Any suggestions? Thanks!
Monitoring - enable new experience
we are trying to explore workspace monitoring which need be done by enabling 'new experience' option under monitoring in workspace settings. when we click on the button nothing happens, sometimes it goes to next screen - once we click on Save, shows error saying, 'feature is not available'. did anyone have similar issue?
Workspace Activities 'Monitoring' not working properly
Hi, I'm using the Monitoring option in a workspace to track the actual activity in my Fabric workspace. I've enabled "Log workspace activity", and it correctly created the Eventstream and the KQL database. However, it seems incomplete. When I open the KQL database, I want to see information such as pipeline activities, semantic model refreshes, and other details. But the only data being collected appears to be SemanticModelLogs. According to Microsoft’s documentation, this monitoring setup should also create a table called ItemJobEventLogs: https://learn.microsoft.com/en-us/fabric/data-factory/monitor-pipeline-runs But it seems that this table is not being created or the data is not being collected in my monitoring KQL. Do you have any idea why this might be happening? Is there an additional setup required? PS: This image is from the Microsoft Documentation, in my Monitoring KQL it doesnt have this table.
DP-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, Amanul
High CU consumption after enabling Workspace Monitoring
Hi everyone, I’m wondering if anyone else has experienced very high CU consumption after enabling Workspace Monitoring in Microsoft Fabric. In my case, I tested it on an F4 capacity, and the additional CU usage was significant enough that the capacity became difficult to use for the actual workloads running in the workspace. I understand that Workspace Monitoring creates and uses Fabric resources for collecting and storing logs, so some additional capacity consumption is expected. However, the overhead I’m seeing feels quite high and it makes no sense to enable this feature I’m interested if there are any answers on following questions: Have you noticed a significant CU increase after enabling Workspace Monitoring? Is the impact especially noticeable on smaller capacities such as F2/F4/F8? Have you found any practical way to reduce the monitoring overhead? Are you using Workspace Monitoring in production on smaller capacities, or do you avoid it because of the CU cost? At the moment, my concern is that on smaller capacities the monitoring workload itself can consume enough capacity to materially affect the workloads it is supposed to help monitor. Would be interested to hear about other people’s experience and whether this is expected behaviour.Deep-Dive: Microsoft Fabric Warehouse Internal Architecture (Polaris, V-Order & Lakehouse Tradeoffs)
Hi Fabric Community, I’ve spent the last few weeks researching and writing a complete architectural guide on the internals of the Microsoft Fabric Warehouse, and wanted to share some key design patterns and takeaways with you. When moving from Azure Synapse Dedicated Pools or SQL Server to Fabric, the mental model shift can be challenging—especially regarding serverless execution and open-standard storage. Here is a summary of the 3 most critical findings from my architecture breakdown: 1. The Polaris Engine Mechanics Unlike traditional Dedicated SQL Pools which bind compute to VM instances, Fabric Warehouse runs on the Polaris distributed SQL engine. Query compilation is split into stateless metadata services. Compute nodes are allocated dynamically per query. There is no local page storage; instead, the engine reads and writes open-source Delta Parquet format files directly in OneLake. 2. The Reality of Constraints A common point of confusion is table constraints. Fabric Warehouse allows you to define Primary Keys, Foreign Keys, and Unique Constraints, but they are not enforced during data ingestion. They serve purely as metadata for the query optimizer (to improve join paths). You must handle data validation/enforcement upstream in your Spark/Dataflow pipelines! 3. Direct Lake & Cold Queries Power BI's Direct Lake mode is a game-changer because it bypasses the SQL endpoint and queries the Delta Parquet files directly. However, if the dataset size exceeds the F-SKU memory limits, the query falls back to DirectQuery mode. This fallback forces the engine to run SQL queries on the SQL endpoint, introducing cold-query compilation times. I have published the full 11,000-word engineering handbook covering capacity planning, monitoring DMVs, security setups (RLS/OLS), and a retail case study. If you are planning an enterprise migration or studying for the DP-600 / DP-700 exams, check out the deep dive here: 👉 Read the Microsoft Fabric Warehouse Architecture & Performance Guide Would love to hear how your teams are managing cold query compilation and metadata cache warming on Fabric SQL endpoints. Let’s discuss below!
