Although we all agree that Polars/Pandas/DuckDB is faster on single node, the Spark Engine has a strong, nearly bug free API that has many efficient implementations (e.g. one of the best Delta/Iceberg/Hudi Writers). It also offers Stream Processing across many matured data sources.   There's nearly 15 years worth of rich tutorials on Spark patterns. Copilot/AI is extremely proficient at producing high-quality Spark code. Data Engineers can be highly productive in Spark in a very short period of ramp up. It is also a great API to learn, since all hyperscalers offer a managed Spark runtime, so it's easy to find a Data Engineering role (job security etc.)   Spark Declarative Pipelines will also significantly reduce the barrier to entry to writing ETL code: Spark Declarative Pipelines Programming Guide - Spark 4.1.0-preview1 Documentation   But - due to the lack of a cheap/fast/single-node runtime, instead of taking advantage of these awesome API investments in Spark Engine, many Data Engineers who have smaller volume of data end up writing entire heterogenous API centric codebases, when they could just use the Spark API and it's innovations, so the code can scale out when the job needs to with simple config changes, or run in local mode when it doesn't need to.   Ideally, one day Fabric could offer a serverless Spark runtime, but until then, it might be fairly easy to tune up a single-node Spark runtime that is opinionated with spark configs that do not force shuffles. Perhaps NEE could back this runtime to reduce the memory footprint as well.   OSS Apache Spark can run pretty fast(er) on a single node if you tweak a few settings. The problem is, you need to be a Spark Expert to read these things and tweak it. It'd be good if Fabric could do this for laymans.   How to Speed Up Spark Jobs on Small Test Datasets How to cut the run time of a Spark SBT test suite by 40% | by Matthew Powers | Medium Setting Shuffle Partitions in order to limit the number of Tasks by qnob · Pull Request #291 · holdenk/spark-testing-base Spark Standalone Mode - Spark 4.0.1 Documentation   For non-distributed datasets on a single VM, Fabric could go ahead and provision a Spark runtime that is Executor heavy, say, on a 6 core VM, do this:   Here's an example of an opinionated spark config ```yaml spark:   local: true                           # Fire spark in local[*] mode   ui: false                               # Turn off Spark UI to save resources   offHeapEnabled: false        # Disable offheap   driverCore: 1                       # Driver doesn't do much, reduce it more if needed   driverMemory: "512mb"    # "   executorCore: 5                 # Executor does the most work, I'm not sure if odd numbers are allowed 🙂   executorMemory: "11.5g"  # "   shufflePartitions: 1             # Don't need shuffles on small data sizes ``` ... View more

I successfully separate Selection State(Selected) from Selection State(Unselected) with transparency option. However, If the user does not make any selection(means selects all) the display of the button is same as Selection State(Unselected). It must be same as Selection State(Selected). Technically, none selected means All selected(same as any selection) ... View more

When datasets are created in BigQuery using the BigQuery API without explicitly specifying a location, the API defaults to the US multi‑region. This default behavior causes issues for users need a way to change the default setting ... View more

Currently, TMDL view is only available in Power BI Desktop.   Please make TMDL view available also in Power BI Service/Fabric in the web browser. ... View more

New Desktop app update installed an almost white user interface. There is zero contrast which is not good for the eyes. I see where some people have requested a light interface so incorporate an option to select either light or dark theme like in the Office apps. ... View more

Microsoft Fabric currently provides the “List Item Connections” REST API, which returns the connections used by a specified Fabric item. However, there is no REST API or UI capability to identify the list of Fabric items that are using a specific connection. This missing reverse lookup makes it difficult to perform impact analysis, governance, and dependency tracking for shared connections.   Users cannot easily determine which items will be affected when modifying or deleting a connection. As a result, managing connections in large workspaces requires manual and error-prone processes. Introducing a workspace-scoped API or UI view to list items associated with a connection would greatly improve discoverability, governance, and operational efficiency. ... View more

Currently, the Workspace Info – Get Scan Result API is available only as an admin-level API and requires either a Fabric/Tenant Administrator role or a service principal explicitly granted access to tenant-level admin APIs. Workspace Admin permissions alone are not sufficient. In many organizations, developers and workspace owners are not allowed to hold Fabric or Tenant Administrator roles due to governance and security policies. As a result, workspace administrators are unable to programmatically retrieve metadata such as Created By, Last Modified By, or item inventory details for the workspaces they manage. At present, there is no supported alternative API that allows workspace administrators to scan or retrieve governance metadata scoped only to their own workspace, which limits self-service governance, auditing, and automation scenarios. Proposed Enhancement Introduce workspace-scoped metadata scan APIs that: Can be executed by Workspace Admins Allow retrieval of item-level metadata such as ownership, last modified details Do not require tenant-level or Fabric Administrator permissions Business Impact Enables self-service governance and auditing at the workspace level Avoids over-privileging users with tenant-wide admin roles Aligns with enterprise security and least-privilege policies Reduces dependency on centralized admin teams for basic metadata needs This enhancement would significantly improve governance capabilities while maintaining strict security boundaries. ... View more

Currently, Microsoft Fabric does not allow naming schedules associated with Fabric items such as pipelines or notebooks. Schedules are system-generated and cannot be given a meaningful, user-defined name. In Azure Data Factory, this capability exists through Trigger Names, which makes identification, monitoring, and governance much easier. Having user-defined schedule names is important for us as we are building dashboards that display running schedules, allowing teams to easily identify, track, and monitor scheduled executions across multiple pipelines or notebooks in a clear and readable way.   We are requesting that Microsoft Fabric add a feature to allow user-defined schedule names similar to Azure Data Factory. ... View more

A 'select all' function in filters could be very useful. Currently, this function only works for all available values, and unfortunately, it doesn't work after a search; you have to manually select the values ​​you've found. Such a 'select all' function after a search would make working with filters much easier. ... View more

I need to conditional format the row header, not just the values section.   Also I would like to be able to format the font in bold/italic and be able to define complete rows (values including row headers) to be underline/overline. ... View more

The UI for using variables in a shortcut could also be enhanced by adding the "Value set name" below the value when shown in the "Manage Shortcut" slide out.   This would indicate which set the value came from to verify it is as desired if you don't recognize the guid (don't we all have every guid in our tenant memorized already? who needs workspace names, I know all the guids!!!)     ... View more

To address the limitations of our current slicers, which are less advanced and potentially confusing compared to our competitors, a new and enhanced list and dropdown slicer should be designed with a wider range of customization options, incorporating industry best practices, and include innovative features like the ability to copy and paste lists. ... View more

Status: Power BI Desktop currently uses a Power BI–specific project structure inside PBIP files, which includes additional metadata files such as definition.pbidataset, diagramLayout.json, and other Power BI–specific annotations. While this structure is required for Desktop functionality, it differs significantly from the clean, TOM‑compatible TMDL folder structure produced by Tabular Editor (“Save to Folder”).  This creates friction for teams who want to: Maintain semantic models in source control using the pure TMDL folder structure Use Tabular Editor as the primary modeling tool Keep Power BI Desktop as a consumer of the model rather than a co‑author Avoid unnecessary metadata churn in Git Track changes on individual artifacts (Columns, Measures,...) Align Power BI Desktop with Azure AS / SSAS / Fabric semantic model workflows Request: Change Power BI Desktop to load and save semantic models directly in the Tabular Editor TMDL folder structure, and add PBIP‑specific metadata files within this structure.    Benefits: Full alignment between Power BI Desktop and Tabular Editor Cleaner Git diffs and better DevOps workflows Easier migration from SSAS/AAS to Power BI Reduced metadata noise More predictable modeling workflows for enterprise teams Why this matters: Tabular Editor’s TMDL folder structure is already the de facto standard for semantic model development. Allowing Power BI Desktop to work directly with this structure would unify the modeling experience across tools, simplify governance, and reduce friction for enterprise deployments. ... View more

Overview Microsoft Fabric provides strong governance constructs for data, semantic models, workspaces, and capacity usage. However, email subscriptions remain governed by a single tenant-wide on/off setting that does not align with how Fabric is operated in controlled enterprise environments. There is currently no supported way to allow managed subscriptions for administrators or reporting teams while preventing end-user self-service subscriptions. Context In many Fabric tenants: Only designated reporting teams are permitted to publish content to Fabric capacities Workspaces, apps, and access are centrally governed Reports often contain sensitive or regulated information Distribution of report outputs is considered a controlled operational activity These tenants do not operate as self-service environments. Instead, reporting teams act as trusted publishers responsible for both content and distribution. Current Limitation Fabric email subscriptions are controlled by a single tenant setting: Enabled: Any user with access to a report can create subscriptions Disabled: No subscriptions can be created, including by tenant admins, workspace admins, app owners, or service principals There is: No security group scoping No role-based permission No admin override No publisher-owned subscription model Fabric capacity, workspace roles, sensitivity labels, and admin APIs do not provide governance over subscription creation or ownership. Why This Is a Problem This design assumes that: Viewing data implies authority to distribute it Subscriptions are an end-user convenience feature In governed Fabric environments, this assumption does not hold. As a result: Native subscriptions must be disabled entirely Organizations are forced to build custom delivery solutions using Power Automate or REST APIs Reporting teams cannot use a built-in Fabric capability for a common enterprise requirement This creates unnecessary complexity for a basic reporting scenario. Requested Capabilities Fabric needs a governed subscription model aligned with enterprise usage patterns. Examples include: Security-group scoped subscription control Allow subscriptions only for specified Azure AD groups (e.g., reporting teams) Publisher-managed subscriptions Subscriptions owned by a workspace, app, or report — not by individual users Role-based permission separation Distinct permission for “Create subscriptions” separate from “View content” Admin override capability Allow tenant or workspace admins to manage subscriptions even when end-user subscriptions are disabled Business Impact Without a governed subscription model: Fabric’s native subscription feature cannot be used in sensitive or regulated environments, e.g., PII or publicly traded entity. Reporting teams cannot provide managed, auditable report delivery using first-party Fabric features. Reporting teams cannot control subscription distributed to Outlook, which leadership considers unsafe. This is not a request for additional self-service functionality, but for controlled, publisher-owned distribution consistent with Fabric’s governance direction. Closing Fabric has made significant progress in enterprise governance. Email subscriptions remain an exception that assumes a low-risk, self-service usage model. Introducing a governed, publisher-managed subscription capability would enable Fabric to better support mature, security-conscious tenants without compromising existing self-service scenarios. ... View more

Mirrored DBs do not support ownership transfer today. This becomes an issue when someone leaves the company. And the user tied to the ownership is beeing disabled. That means you need to recreate the whole mirroring database and recreate all shortcuts, jobs pipelines etc etc.. Alot of work. The Take‑Over functionality exists for other Fabric items but excludes mirrored DBs. This is a critical operational need for enterprise workloads. Please consider developing this functionality.  ... View more

  Currently, colors are automatically assigned randomly.  It would be nice if your dev workspace was always blue, and your prod was always pink for example.  Then you'd have a good visual as to where you're working in. ... View more

It would be helpful to add dynamic context to visuals using a measure within this field:     ... View more

Consider a test user who has been assigned Lakehouse  Write permission to a specific folder in a Fabric Lakehouse using one lake security roles. This permission reflects correctly in Azure Storage Explorer, and the user can access the folder as expected. However, the permission does not appear correctly in OneLake Explorer. Specifically, the Lakehouse does not appear under 'My Workspace' in OneLake Explorer for that specific user. Seems like a limitation with the one lake explorer as it is still in preview. Would be of great help if this is fixed. ... View more

Today, changing collation settings such as case‑sensitive or case‑insensitive behavior in Semantic Models and Lakehouse environments is not straightforward. It usually requires using JSON DDL scripts, advanced SQL commands, or backend configuration changes. This makes the process difficult for many users. Business users are unable to manage it on their own, and even technical users often find it complex and error‑prone. Small mistakes can lead to misconfiguration, unexpected query results, or broken relationships. In many cases, customers need to raise support tickets or rely on experts to make these changes, which slows down their work. The experience is also inconsistent across different artifacts. In Lakehouse scenarios, collation behavior is tightly linked to the SQL endpoint, which adds more complexity and confusion. Customers generally expect such a basic and important setting to be available through a simple, guided user interface instead of low‑level scripts and manual steps. Proposed Solution Introduce a simple, user‑friendly button in the UI that allows users to control collation behavior without needing scripts or advanced configurations. For Semantic Models or Datasets, add a Collation Mode option under Model Settings. This should be presented as a clear toggle or button where users can switch between Case‑Insensitive and Case‑Sensitive. The button should include brief, helpful text explaining how the selected option affects DAX queries, SQL queries, relationships, and overall performance. This allows users to understand the impact before making the change. For Lakehouse and SQL Endpoints, add a Collation Configuration button directly in the Lakehouse settings and SQL Endpoint settings. With a single click or toggle, users should be able to choose between Case‑Sensitive and Case‑Insensitive behavior. Once selected, the setting should be applied consistently across tables, metadata, and query execution to ensure predictable and consistent results. By introducing a simple button or toggle in the UI, customers can manage collation settings confidently and independently. This removes the need for manual scripts, reduces errors, improves consistency across artifacts, and provides a much better overall user experience. ... View more