OneLake Catalog full-text and content search
Why is it not possible to search OneLake by item description or even content? So I was thinking about how a user can find a table if they don't know in which lakehouse it is located? Why can't you search the description to be able to only find a fabric item by its (sometimes "cryptic") name but by a description? Use-Case: I want to have a data mesh where people can make data sets available and share them easily. So how can someone find the lakehouse where financial data is shared (when the lakehouse is called FinRep) or where to find dim_account? Is this always a case for Purview? No way that we can make that available in Fabric directly?Support OneLake Security-Enforced Data Sources in Fabric IQ Ontology
Fabric IQ Ontology is designed to provide governed business context across enterprise data, while OneLake Security is becoming the central fine-grained security model for Fabric. These capabilities should work together directly. I would like Ontology data bindings to fully support Lakehouses that use OneLake Security, including table/folder permissions, row-level security and column-level security. Ontology queries, Graph exploration, Data Agents and other consumers should respect the effective OneLake permissions of the requesting identity. Administrators should not have to choose between securing a Lakehouse with OneLake Security and using that data as part of a Fabric IQ ontology. Integrating the two would provide a consistent security boundary from OneLake data through business concepts, relationships and AI experiences.Allow External OneLake Data Shares to Be Accepted into Multiple Fabric Item Types
Fabric External Data Sharing provides an excellent zero-copy mechanism for sharing OneLake data across tenants. However, the receiving tenant currently has to accept the share into a Lakehouse. I would like the consumer to be able to choose the Fabric item that best matches the consuming workload, including Lakehouse, Warehouse, Eventhouse/KQL Database and SQL Database where technically applicable. For example, a team whose primary consumption environment is Fabric Warehouse should not need to create and operate an additional Lakehouse simply to receive an external share. The external share should remain governed and read-only while appearing natively in the selected Fabric workload. This would make cross-tenant OneLake sharing more consistent with Fabric's multi-workload architecture and reduce unnecessary intermediate items.Allow OneLake Shortcut Authentication Mode to Be Changed In Place
OneLake shortcuts support passthrough and delegated authentication, but changing the authentication model currently requires deleting and recreating the shortcut. I would like shortcut authentication and connection settings to be editable in place. Administrators should be able to change a shortcut from passthrough to delegated authentication, replace the delegated connection identity, or move back to passthrough without deleting the shortcut. Fabric should validate the new identity and permissions before applying the change and preserve the shortcut object, downstream references, lineage and dependent workloads. For enterprise environments, security models and service identities evolve over time. Recreating shortcuts increases operational risk and makes automation more difficult. Making authentication a manageable property of the shortcut would improve lifecycle management, security operations and CI/CD.Add an "Explain Effective Access" Experience for OneLake Security
As OneLake Security expands across tables, folders, rows, columns and shortcuts, determining why a specific user can or cannot access data can become difficult. I would like Microsoft Fabric to provide an "Explain Effective Access" experience for OneLake. An administrator should be able to select a user, service principal or group and a OneLake path and see: - workspace and item permissions - applicable OneLake security roles - RLS and CLS policies - shortcut-path permissions - target-path permissions - whether passthrough or delegated authentication is being used - which identity each query engine uses - the resulting effective access - the specific rule responsible for allowing or blocking access The same information should be available through an API for security automation and audit tooling. This would significantly simplify troubleshooting, security reviews and least-privilege validation in enterprise Fabric environments.Tenant-Wide OneLake Shortcut Lineage and Impact Analysis
This is grounded in a documented limitation: shortcut lineage is currently workspace-scoped, and Microsoft specifically says lineage for shortcuts to warehouses and semantic models isn't currently available. There are also community discussions describing the inability to trace table-level dependencies across workspaces.
Display Delta table and column descriptions in Fabric Lakehouse Explorer/ Fabric on Browser
Microsoft Fabric Lakehouse should provide a visible and editable description field for Delta tables and columns in Lakehouse Explorer. Delta table metadata, such as comments or custom description properties, can be stored through Spark, but this information is not clearly displayed to users browsing the Lakehouse. Please add support for: Displaying table descriptions in Lakehouse Explorer/ Fabric on Browser Displaying descriptions as tooltips or in a table details panel Displaying column descriptions in table previews and schema views Editing table and column descriptions directly from the Fabric interface Reading existing Delta comments and description properties Exposing descriptions consistently through the Lakehouse SQL analytics endpoint Making descriptions available to Microsoft Purview and Copilot This would improve data discovery, self-service analytics, governance, and semantic understanding without requiring users to maintain separate documentation. Data engineers can identify tables from technical names, but report developers, analysts, and business users need descriptions to understand their intended purpose. Keeping descriptions directly with the Lakehouse object reduces separate documentation, ambiguity, and incorrect table usage.Show the workspace name for duplicate SQL endpoints with the same name in Desktop PowerBI
When multiple Fabric SQL endpoints have the same name, Power BI Desktop should display the source workspace name alongside the endpoint name during connection and in imported table metadata, so users can distinguish between dev, test and prod sources. Currently the only thing to determine in the report is connected to a dev, test or prod SQL endpoint is to look at the SQL endpoint ID which is still not clear and requires users to wither reconnect or open the workspace in the web and get the SQL endpoint ID that way.
Enable Data Buy & Sell Across - Fabric, Non-Fabric, Tenants and Regions
Requested Enhancement: Enable Microsoft Fabric Marketplace capabilities that allow organizations to seamlessly buy, share, and sell data products across: - Fabric and non-Fabric environments - Different Microsoft Entra tenants (cross-tenant) - Different Azure regions (cross-region) The experience should provide a unified marketplace where organizations can discover, purchase, subscribe to, and consume data products regardless of whether the provider or consumer is using Fabric. Similarly, organizations should be able to publish and monetize data products for both Fabric and non-Fabric consumers without requiring complex data-sharing, integration, or onboarding processes. Key Requirements: - Support data product buying and selling between Fabric and non-Fabric platforms. - Enable seamless cross-tenant data commerce and sharing. - Enable cross-region data discovery, subscription, and consumption. - Provide a consistent marketplace experience for data providers and consumers. - Simplify onboarding, governance, billing, and access management for marketplace transactions. Business Value: - Creates a global data marketplace that extends beyond the Fabric ecosystem. - Unlocks new revenue opportunities by allowing organizations to monetize data assets across tenants, regions, and platforms. - Simplifies secure data sharing and collaboration between business partners, customers, and suppliers. - Reduces friction associated with cross-region and cross-tenant data exchange. - Positions Microsoft Fabric as a central hub for enterprise data commerce, enabling seamless buy-and-sell experiences across the broader data ecosystem.
Ability to delete system restore points in the data warehouse
Since the restore points count towards consumed (and billable) storage: "The creation of both system-created and user-defined restore points consume storage. The storage cost of restore points in OneLake includes the data files stored in parquet format. There are no storage charges incurred during the process of restore." we would like to be able to delete restore points. The current reasoning behind this option not being available is to meet the SLAs. I don't see it as valid reason as by deleting a restore point we acknowledge that meeting the recovery SLA is affected. We would like to be able to choose between paying for storage or having ability to restore a state from the past.
