Please make it possible to interactively run a Notebook as a Workspace Identity, Service Principal or Managed Identity.   Purpose: This would allow us to connect to resources that our personal user account doesn't have access to. This would allow us to interactively test notebooks using the Workspace Identity, Service Principal or Managed Identity before we include the notebook in a pipeline. This way, we could test: the identity's access to data sources and the notebook code's functional compatibility with running as SPN/WI/MI (because not all notebook functionality like semantic link is compatible with SPN, we'd like to be able to test this interactively before including the notebook in a pipeline). ... View more

Currently, Microsoft Fabric supports notifications only at the overall capacity level, which makes it difficult to proactively identify individual artifacts driving high CU consumption. This idea proposes enabling per‑artifact capacity usage alerts for semantic models, reports, and other items. Admins could define CU thresholds at the artifact level and receive notifications when those limits are exceeded. This would help quickly isolate high-impact artifacts, reduce capacity contention, and improve governance and operational efficiency. ... View more

Currently, you can hit weird errors or slow performance when trying to open items in a workspace that is linked to a paused capacity.   It would be a real quality-of-life improvement if there would be a small message or popup showing when a workspace is linked to a paused capacit.   ... View more

Description Microsoft Fabric strongly promotes concepts such as “Zero-ETL”, OneLake Shortcuts, Mirroring, and Direct Lake to reduce traditional ETL complexity. However, in real-world enterprise environments—especially hybrid architectures with on‑premises systems—ETL is often unavoidable, and this is where a critical gap appears. The Core Problem When Microsoft Fabric accesses on‑premises data through the On‑Premises Data Gateway (ODG): ODG can consume a large portion of on‑premises → cloud network bandwidth Neither Fabric nor ODG provides: Bandwidth throttling Rate limiting QoS or prioritization There is no first‑class observability for: Which pipelines or copy activities are responsible How much data they transfer When and how they saturate network links By contrast, Power BI semantic model refreshes are well covered by: Capacity Metrics Refresh history CU consumption visibility But Fabric Pipelines / Copy activities / Dataflows Gen2, which are often the largest network consumers, are not covered with comparable visibility. Why This Matters In enterprise networks: On‑premises bandwidth is shared with mission‑critical systems Uncontrolled ETL traffic can: Degrade core business systems Trigger operational incidents Block adoption of Fabric regardless of its analytical strengths Currently, customers are forced to: Infer ETL impact indirectly Manually correlate timestamps across multiple systems Treat ODG as a “black box” despite it being the critical choke point This is not a tooling inconvenience but a platform‑level design gap. Comparison with Other Platforms Other cloud data platforms explicitly address this concern: Databricks Provides pipeline‑level observability Supports rate limiting (e.g. maxBytesPerTrigger) Exposes network and throughput metrics as first‑class signals Snowflake Treats ingestion as a managed “entry point” Provides clear ingestion metrics and accountability per channel Microsoft Fabric, in contrast, effectively says: “Reduce ETL wherever possible,” but provides no adequate answers for unavoidable ETL. What This Idea Requests At minimum, Fabric should provide one or more of the following: Pipeline‑level observability for ODG traffic Data volume transferred Execution time Gateway‑level saturation indicators Correlation between Fabric Pipelines and ODG execution Even coarse, time‑window‑based correlation would help Optional throttling or rate‑limiting controls Per gateway Per pipeline or activity An official, supported monitoring story Instead of forcing customers to rely on log scraping or community workarounds Closing Thought “Zero‑ETL” is a valuable direction. But until ETL is truly eliminated, Microsoft Fabric must treat ETL traffic—especially via ODG—as a first‑class operational concern, not as something “outside the platform boundary.” Without this, Fabric adoption in serious hybrid enterprises will remain unnecessarily fragile. ... 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

In one of the projects I'm involved in, we found out that deleting an item is irreversible. When you hit delete, the item is gone and all the data in it as well. There is a retention period for workspace deletion but, unless I've missed something, not for items. In the discussion with the client, we found that a very elegant solution would be to create a separate role that allows for deletion of items. Or, as an alternative, introduce the delete locks as seen within Azure.  In both cases, deleting items will become harder and that is the exact point. I think the option to enable delete protection is something for the admin portal. It should only apply to non-personal workspaces and, from the admin portal, workspaces can be exempted from delete protection. This way, dev workspaces can be a 'free for all' whereas QA and Production are heavily protected against accidental deletes. If you want to go really granular, there could be an option to select Lakehouses to be protected, but notebooks can be deleted. ... View more

We need support for Service Principal authentication when creating Lakehouse connections.   Right now, Lakehouse connections can only be created using a user account. As a result, Dataflow Gen2, Pipeline copy activity, and Copy Job cannot use a Service Principal (SPN) when connecting to a Fabric Lakehouse as a source or destination.   This is an issue for us. We want to avoid user-based connections because: We need environment-specific identities (dev/test/prod) to prevent accidental cross-environment writes (e.g., dev pushing data to prod). Tying connections to personal user accounts creates fragility - things break when someone leaves the project or the organization. Service Principal support for Lakehouse connections is required to ensure secure, reliable, and environment-isolated authentication.   The screenshot shows that only user authentication is available, not service principal authentication. ... View more

Centralized Purview configuration has setup sensitivity labels. Some of the labels have email controls, e.g. "Internal" labeled emails can only be sent to the company mail domain recipients, while "External" labeled emails can be sent to recipients that does not have company domain email. This is in effect and is working when sending email through Outlook clients. The Purview configuration for the sensitivity labels have been enabled for Fabric. Users can set the sensitivity labels on objects in Fabric. Before I continue, please note that there is a Fabric tenant setting for "Users can send email subscriptions to external users" - we are using this setting today for specific user groups.   When creating a Power BI subscription, regardless of if it's a Power BI report or for a Power BI Paginated report, there is the information that "The sensitivity label on this report/paginated report does not appear in emails." Also note that Power BI subscriptions are not using the company tenant mail service to send subscriptions, subscriptions are sent from a Microsoft owned mail service.   Correct sensitivity labels are set on attached report output (in our case, when attaching the output as either PowerPoint, Excel, Word. No sensitivity labels are set on the actual email, which is documented. The controls set through the company tenants Purview on sensitivity labels, such as who to send to is not adhered.   The issue and the idea is that unless you can implement that your (Microsoft) mail service that is used by to send the subscriptions can recieve and follow the controls by the company tenant Purview configuration - which would be the ideal setup since Purview should be able to work in Azure, in all components - then as a second idea would be to allow us to use our own mail services which know of and follow the controls, for Power BI subscriptions, which does not seem to be possible today. ... View more

Manage data source connections in a folder hierarchy. This improves governance for data sources and prevents connections that should be shared across projects or data teams from being listed together with personal connections in the same flat list. Use folders for data source connections to manage permissions for multiple connections at once. This avoids the pain of having to manage users and access separately for each individual connection when there are many connections. ... View more

Microsoft Fabric is increasingly being adopted as a corporate, shared, and mission‑critical analytics platform in enterprise environments. In many organizations, operational monitoring and alerting are centralized in enterprise observability tools (such as Dynatrace, Datadog, Splunk, etc.), and operational teams are not expected to rely on product portals or UI‑based monitoring for day‑to‑day incident detection. Today, Microsoft Fabric provides valuable capacity health and consumption signals (including throttling proximity indicators) through Real‑Time Hub and Capacity Overview Events. However: There is no native API or webhook to expose Fabric capacity health and consumption metrics directly to external systems. Integrating Fabric with enterprise observability platforms currently requires building custom solutions using Real‑Time Intelligence (Eventstream, Eventhouse, or custom endpoints). While Real‑Time Intelligence is powerful, it introduces additional architectural complexity for what is a very common enterprise requirement: basic health, consumption, and alerting integration. Requested capability We propose that Microsoft Fabric provides native, supported interfaces to expose capacity telemetry, such as: Capacity health status Capacity utilization / consumption Throttling risk or proximity indicators Capacity state changes These interfaces could be exposed via one or more of the following: REST APIs Webhooks Standard event endpoints designed for third‑party integrations Why this matters Providing direct APIs or webhooks would: Enable seamless integration with enterprise observability platforms Reduce the need for custom Real‑Time Intelligence implementations Improve operational maturity, governance, and compliance Align Microsoft Fabric with enterprise operational standards, where monitoring is centralized and automated This capability would significantly improve the operational readiness of Microsoft Fabric for large organizations running Fabric as a shared, business‑critical service. ... 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

The Default Value Set in the Variable Library poses a risk.   The Default Value Set will silently apply values when no explicit value set has been selected for a Test or Prod workspace.   There is no warning if we forget to select a value set in Test and Prod. This can result in deployments incorrectly using Dev values in Test and Prod - without any warning. Fabric should allow us to disable or remove the Default Value Set, and require every workspace to explicitly select a value set. ... View more

The Problem: Currently, there is no centralized way for a Fabric or Power BI Administrator to extract the offline (compressed disk) size of all semantic models across a tenant. While individual sizes can sometimes be found via the XMLA endpoint or by manually checking the Capacity Metrics App, there is no REST API or Scanner API attribute that exposes this data at scale. Microsoft has previously noted that this information is not currently exposed in any API. This creates a significant blind spot for administrators who need to: Manage Capacity Growth: Identify which models are approaching the "Max Offline Dataset Size" limits set in the Admin Portal. Optimize Costs: Pinpoint bloated models that are consuming excessive storage or will require large memory footprints upon loading. Proactive Governance: Automate reporting on tenant-wide storage trends to prevent capacity exhaustion before it happens. The Proposed Solution: Update the Power BI/Fabric Admin REST APIs (specifically the Scanner API or Get Datasets In Group) to include a metadata field for offlineSizeInBytes. Ideally, this should provide: The compressed size on disk (Offline Size). Integration with the Fabric Capacity Metrics App: A dedicated, exportable table showing the size of all items, not just those recently active. Historical Snapshotting: The ability to see how a model's offline size has grown over time via standard admin logs. Why this is important for Fabric: As we move toward a more unified Fabric experience, storage and compute are billed and managed more strictly. Knowing the "weight" of a semantic model before it is loaded into memory is a fundamental requirement for any enterprise-grade "Flight Dashboard." We cannot manage what we cannot measure at scale. ... View more

  The current inability to parameterize connections in pipeline activities means we need to use the same identity to run the pipeline activities across dev/test/prod environments.   This means the same identity needs to have write access to all environments dev/test/prod.   This creates a risk that code executed in dev writes data to prod, because the identity has write access to all environments.   Please make it possible to parameterize the connection of all pipeline activity types, so we can isolate the identities for dev/test/prod and make it physically impossible for a dev pipeline activity to write data to prod environment.   Here's an overview based on my trials and errors:   Activities that do have "Use dynamic content" option in connection:   - Copy activity  - Stored procedure  - Lookup - Get metadata - Script - Delete data  - KQL   Activities that do not have "Use dynamic content" option in connection:   - Semantic model refresh activity  - Copy job - Invoke pipeline - Web - Azure Databricks  - WebHook - Functions - Azure HDInsight  - Azure Batch  - Azure Machine Learning ... View more

Today, only Oauth 2.0 (user account) is supported as authentication option when setting up an Azure Key Vault reference.   Please add support for Workspace Identity  Service principal User assigned managed identity ... View more

Similar to the Monitor page, where we can see what has run and what is currently running, it would be useful to see what's scheduled to run in the future. This to check that all schedules are set up as expected.   Reason: Easy and conveniently verify that all schedules are configured as expected. ... View more

Problem Renaming a Library Variable in Microsoft Fabric does not update pipelines that reference it. The pipeline continues to contain the old expression name and only fails at runtime. There is also no warning during publish or validation. In real projects this creates silent breaking changes. A simple refactor can cause multiple pipelines to fail in production without any design time indication.   Why this matters This affects maintainability and safe refactoring. Large Fabric workspaces often contain many pipelines and variables. Currently teams must manually search every pipeline JSON to avoid outages.   Typical scenarios impacted: • Renaming variables to follow naming standards • Environment standardization • CI/CD promotion between environments • Shared library cleanup   Suggested solution Fabric should track Library Variable usage as a dependency rather than plain text and support safe rename operations. Possible implementations: Option A When renaming a Library Variable, automatically update all pipeline expressions referencing it. Option B Show a dependency impact list before rename and allow refactor confirmation. Option C At minimum, show validation warnings for broken references during publish.   Expected benefit This would significantly reduce production failures caused by refactoring and align Fabric behavior with modern IDE refactor capabilities. Current behavior makes variable rename a breaking change, which discourages proper governance and cleanup of shared libraries. ... View more

To make it easy to filter workspaces, and also enable cost chargeback scenarios, it should be possible to apply Tags to workspaces. ... 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