We love Polars. It is user friendly and it works great for our data volumes.   Today, V-Order can be applied to delta parquet tables using Spark notebooks, but not Python notebooks.   Please make it possible to apply V-Order to delta parquet tables using Polars in pure python notebooks.   We encourage Microsoft to cooperate closer with Polars, as most customers can save a lot of CUs (money) by switching from Spark (distributed compute) to Polars (single node). ... View more

It would be beneficial to add when creating a connection for Azure SQL Database from Settings > Management and Connection Gateways to have the option of authenticating with Service Principal. Currently the only option for authenticating for the connection is OAuth 2.0 that it acts as user connection. When a CICD devops pipeline is used to deploy (like using Fabric CI CD opensource library), The SP doesn't have access to connection and therefore fails. ... View more

As already reported and discussed here: https://community.fabric.microsoft.com/t5/Data-Engineering/Some-methods-in-notebooks-do-not-work-when-executed-from-Data, and based on the feedback from Microsoft support that this is a known issue and that an Idea should be opened for this - I suggest this issue is further analyzed and a fix or workaround is suggested.   Reference support case I opened (and also more people opened the support case with the same issue): 2504161420001430 ... View more

Please add support for: configurable session timeout for Pure Python notebooks explicit session termination after notebook completion This would improve capacity efficiency, operational control, and make Pure Python notebooks easier to use in scheduled and automated workloads. ... View more

Make it possible to write SparkSQL without having a Default Lakehouse.   With 3- or 4- part naming, i.e. [workspace].[lakehouse].[schema].[table]    there should be no need to attach a Lakehouse in order to use SparkSQL.   Needing to attach a Lakehouse is annoying and adds extra complexity. ... View more

Currently, when using the semantic model UI at 100% zoom on smaller screens or lower resolutions, table fields are not visible, making table selection impossible. Reducing zoom (e.g., to 80%) or using a higher-resolution display resolves the issue, which indicates a UI scaling and responsiveness limitation. ... View more

Currently docstrings/intellisense do not work for custom libraries in fabric notebooks.  This has been confirmed as a feature gap and is on the backlog  https://www.reddit.com/r/MicrosoftFabric/s/G0irMOtdrC   Vote for this idea to bring a feature to fabric that will be celebrating it's 30th anniversary in visual studio this year!  ... View more

Hi,    We have numerous clients running Quantios Core, which is Dynamics 365 Business Central with an extension from Quantios to include new tables and functionality within Business Central for the product QCore.   We want to do our reporting, analysis, and merging other data sets in Fabric but having issues getting data into Fabric.   Would it be possible to get mirroring up and running so that we can have the source system data within Fabric managed by Microsoft so that we can get busy with analytics, modelling and reporting for our clients.   Thank ... View more

Problem Currently, Microsoft Fabric capacities run continuously once they are enabled. Many organizations only need Fabric workloads during business hours (for example, Monday–Friday, 9 AM–6 PM). If the capacity continues running outside these hours, it can lead to unnecessary compute costs. At the moment, administrators must rely on external automation tools such as: Azure Automation Power Automate to schedule capacity start and stop operations. While these solutions work, they require extra setup, permissions, maintenance, and monitoring. Proposed Solution Introduce a built-in scheduling feature inside Fabric Capacity Settings that allows a Tenant Admin or Capacity Admin to define when a Fabric capacity should automatically start or stop. Example scheduling options could include: Start capacity at 8:00 AM Stop capacity at 7:00 PM Capacity pause during weekends Custom schedules for holidays or non-working days This configuration could be added directly in: Fabric Admin Portal → Capacity Settings → Scheduling Benefits Cost Optimization Organizations only pay for capacity when it is actually needed. Simplified Administration No need to configure external automation scripts or workflows. Built-in Governance Centralized scheduling managed directly inside Fabric. Better Cloud Cost Control Especially useful for development, testing, and non-production capacities. Real-World Example A company runs its analytics workloads during business hours only. Instead of running Fabric capacity 24/7, the admin could configure: Start: 8:00 AM (Monday–Friday) Stop: 7:00 PM (Monday–Friday) Paused on weekends This could significantly reduce operational costs while maintaining performance during working hours. Why This Matters As adoption of Microsoft Fabric grows, organizations are increasingly focused on cost governance and efficiency. Providing native scheduling for Fabric capacity would be a highly valuable feature for many customers. 👍 If you find this idea useful, please vote so the Microsoft Fabric team can consider adding this feature. ... View more

Hello Microsoft Fabric Product Team, In Microsoft Fabric, the SQL Analytics Endpoint is a critical consumption layer for Lakehouse data, especially for downstream systems, reporting tools, and automated jobs that rely on T‑SQL access. Today, there is no official or exposed metadata indicating when the SQL Analytics Endpoint was last synchronized with the underlying Lakehouse data. The refresh process is asynchronous, and while activities such as “Refresh SQL Analytics Endpoint” exist, they do not provide: a reliable last refresh timestamp, a refresh completion status that can be queried programmatically, or a way to correlate Lakehouse data availability with SQL endpoint readiness. Problem In production environments, this lack of visibility makes it difficult to: Validate data freshness after Lakehouse pipelines complete Diagnose data latency issues between Spark (Lakehouse) and SQL consumers Coordinate downstream jobs that depend on up-to-date SQL data Implement governance or SLAs around data availability Teams are often forced to rely on empirical testing (data comparisons, polling, manual verifications), which is fragile and operationally costly. Proposed Enhancement Expose a system-level indicator for the SQL Analytics Endpoint such as: LastSuccessfulRefreshTimestamp Optional RefreshStartTime / RefreshEndTime Refresh status (e.g., InProgress, Succeeded, Failed) This information could be made available through one or more of the following: A system DMV or system table in the SQL Analytics Endpoint Lakehouse or workspace metadata (Fabric UI / APIs) Pipeline activity outputs or logs Fabric monitoring or governance endpoints Benefits Providing this visibility would: Enable deterministic orchestration between Lakehouse pipelines and SQL consumers Improve troubleshooting and reduce false data-quality incidents Support enterprise-grade governance, observability, and SLA definitions Increase trust in SQL-based consumption of Fabric Lakehouse data This feature would significantly improve operational clarity for customers running production workloads on Microsoft Fabric. Thank you for considering this suggestion. Best regards, Rafael Tiago Alves Ribeiro Data Architect SQ / Microsoft Fabric User ... View more

Introduce advance notifications and an auto-tracking dashboard for monthly Data Gateway updates to help teams proactively manage changes and minimize client impact ... View more

As a senior Power BI Data Analyst and consultant, I am raising a critical developer experience gap introduced by Direct Lake semantic models that is significantly impacting my ability to do my job effectively. The following capabilities — which are standard and essential in Import and DirectQuery modes — are missing or broken in Direct Lake: 1. TABLE VISIBILITY IN THE LEFT PANEL (DESKTOP) When connected to a Direct Lake semantic model in Power BI Desktop, tables are not visible in the left-hand Data panel. This is a fundamental requirement. I need to see my tables to validate data, spot anomalies, check row counts, and verify that upstream data engineering has loaded correctly. Without this, I am building reports completely blind. 2. TABLE/DATA VIEW IN THE SERVICE The Power BI Service does not expose underlying table data in a browsable view. When a Data Engineer makes a pipeline change that introduces a data type mismatch, incorrect values, or broken relationships, I have no way to detect this from within the semantic model. I should not need to leave the Power BI environment and open a SQL analytics endpoint just to inspect my own model's data. 3. DATA TYPE MANAGEMENT I cannot change or correct data types on Direct Lake tables in either Desktop or the Service. Data type issues are a daily reality in analytics — source systems change, ETL pipelines evolve, and the BI developer is often the last line of defence before incorrect data reaches an executive dashboard. Removing this capability removes a critical quality control mechanism. 4. CALCULATED COLUMNS IN DESKTOP I cannot add calculated columns to a Direct Lake semantic model in Power BI Desktop. Calculated columns are a legitimate and widely-used modelling tool, particularly for categorisation, banding, and label generation logic that belongs in the semantic layer — not hardcoded in upstream SQL or ETL pipelines. The broader issue is a philosophy problem: Microsoft appears to assume that the Data Engineer and the BI Developer are always separate people working in perfect coordination. In reality, many Power BI professionals span both roles, and even in team environments, the BI developer must be able to validate, inspect, and augment the semantic layer independently. Direct Lake is a genuinely powerful technology. But the current developer experience is a significant regression for professional Power BI developers who have built workflows around Desktop-first development over many years.   I urge Microsoft to restore these capabilities as a priority. Power BI's strength has always been empowering analysts to work with confidence and visibility. Please do not take that away in the name of cloud-first architecture. ... View more

When running a Notebook in the security context of a Service Principal, unfortunately notebookutils.credentials.getToken('pbi') and notebookutils.credentials.getToken('https://api.fabric.microsoft.com') only return a few scopes:   * Dataset.ReadWrite.All * Lakehouse.ReadWrite.All * MLExperiment.ReadWrite.All * MLModel.ReadWrite.All * Notebook.ReadWrite.All * SparkJobDefinition.ReadWrite.All * Workspace.ReadWrite.All   This severely limits the usability of the token when working in Fabric for other item types and Fabric REST APIs. Please make it so that the token can access all item types and all Fabric REST APIs.   The Service Principal has Contributor access to the workspaces and the Notebook is executed in the security context of the Service Principal.   Ref.: https://www.reddit.com/r/MicrosoftFabric/s/OoUhmOT1qg ... View more

Lakehouses, and more importantly the data inside them, are not recoverable if the the lakehouse is deleted. There is also no way to recover a prior lakehouse if the data needs to be rolled back to a previous state. BCDR was recently released but is only for capacity disaster recovery and is too cumbersome as it has an extra cost along with deploying in another region. We need a way to recover a lakehouse and its history, if it has been deleted or if the data has been corrupted. ... View more

Problem When developing or operating Warehouse‑backed models, we often need small, surgical data fixes - e.g., correcting an erroneous valid_to_dt in an SCD2 dimension or updating a junk‑dimension attribute. In SQL Server/SSMS, the “Edit Top N Rows” grid makes this fast and safe. Fabric Warehouses currently lack a GUI row editor, pushing teams to external tools (e.g., DataGrip) or ad‑hoc DML scripts. This creates friction, slows incident resolution, and fragments tooling—even though Warehouses already support full DML via T‑SQL.   Proposal Provide a first‑class “Edit Top N Rows” experience for Warehouse tables: Fabric Portal: grid editor with inline add/edit/delete, filter, and commit/rollback. SSMS / VS Code: enable the same grid or a lightweight editor with “generate DML” preview. Respect Warehouse permissions/RLS; optionally log changes via SQL Audit Logs and take a Time‑Travel snapshot for quick rollback. Why this matters Speeds data quality hotfixes, removes the need for competitors’ tools, and lets us fully standardize on VS Code + SSMS + Fabric while retaining governance and safety. ... View more

Currently, workspaces use a flat structure; adding folder metadata retrieval would allow automation for external storage replication (e.g., S3). ... View more

While CI/CD support for Job Schedules can be a useful feature, it is not always desirable.   It would be better if users could choose whether this is enabled for a workspace or via something like a .gitignore or perhaps .schignore for more fine-grained control.     ... View more

The ability to parameterize the connection would enable using separate identities (e.g. separate service principals) for dev/test/prod environments.    Having to use the same SPN in dev/test/prod introduces unnecessary risks, like accidental data modification across environments - a dev workload accidentally writing to production data, or a production workload accidentally connecting to and using data from the dev environment.   This would be solved if we could use variable library to reference the corresponding connection id for dev/test/prod service principal.   Unfortunately, the connection property in pipeline's notebook activity does not support Dynamic Content yet.   Please make this possible so we can avoid the risk of cross-contamination between environments. ... View more

A Fabric item can now have up to 20 schedules attached to it.   These schedules can have different purposes, let's say one is for nightly runs and another one is for runs during working hours.   If we want to update a schedule via API, we need the schedule ID.   To get the ID, we can list the schedules. But, there's no easy way to pick the relevant schedule from the returned list or schedules - because there's no name or description associated with a schedule object.   Please add the option to create a name or description for an item schedule.   This could also show up in the run log of an item (run was triggered by schedule [Name]) which would provide useful context for the run.   It could also be cool if an item could pick up the schedule name as a "TriggeredBy" property and potentially execute conditional logic depending on which schedule triggered the run. ... View more