Can you please update this so multiple people have ownership to update the subscriptions?  This causes dis-satisfaction when someone moves departments are leaves the company.  ... View more

Currently, the Capacity metrics app only shows data from the last 14 days regarding Capacity Consumption. This amount of data is insufficient, and the Customer would prefer to view capacity consumption by month to better understand their monthly usage. To get 30 days of data, they must manually export the 14-day data, as there is no automation for this process. This makes it difficult for the Customer to review their Capacity consumption for an entire month. ... View more

When using the Power BI JavaScript SDK to add custom context menu extension commands via report.updateSettings(), the commandTriggered event never fires for the "New Card" visual (internal type: cardVisual). The custom menu items render correctly in the context menu, but clicking them produces no event, no error, no callback, nothing.   This works correctly for all other tested visual types including the legacy Card (card), bar charts (lineStackedColumnComboChart), and others. Only the cardVisual type is affected   Steps to reproduce: Embed a Power BI report using powerbi-client (tested with v2.23.1 and v2.23.10) Register extension commands and groups via report.updateSettings() with extensions.commands and extensions.groups Register a handler: report.on("commandTriggered", callback) Right-click on a "New Card" visual and select any custom extension command Observe that the callback is never invoked   The issue is not in the client library, the postMessage from the iframe is never sent for cardVisual types, confirmed by monitoring window.addEventListener("message", ...) Upgrading from powerbi-client v2.23.1 to v2.23.10 does not resolve the issue The Power BI embedded SDK does not provide a mechanism to hide extension commands per visual type, so there is no workaround to prevent users from seeing non-functional menu items on cardVisual visuals ... View more

Scheduling Hub   It would be great to to be able to see which items in your fabric workspace (and capacity) have schedules and if they are on or off. A bonus feature would allow you to enable and disable the schedules right from the list view (editing could still open the item in the editor and open the scheduling pane).   Being able to manage schedules from a central location is helpful in 'emergency' scenarios where you need to turn off all the pipelines and notebooks for a workspace. It could also be useful to ensure developers are not mismanaging schedules in Dev or Feature Branch workspaces (where we might typically not want them running). A whole set of useful columns are possible: Item Name  <click on the name to go to the item!> Item Type Workspace Schedule Type Next Scheduled Run Last Scheduled Run   Icons.. Edit Pencil, Enable/Disable, Trash Can The possibilities are endless!   ... View more

It would be nice for app only users (no access to the underlying premium workspace) be able to search for a report that is in an app they have access to while in the PBI service. Currently it is only searchable to those added to the workspace. ... View more

When a parameter is created with numeric range and data type decimal with maximum value 5000 and increment of 0.1 and used in a slicer, the input numbers rounds off to nearest whole number. Example: when user enters 2 in the slicer, then the input is taken as 0 and if 3 is entered then rounds to 5 which is the nearest whole number. When a parameter reaches the limit of 1000 as per document, additional values cannot be loaded, which restricts its usability in real‑world enterprise scenarios. Many organizations rely on parameters to dynamically filter large datasets, such as user lists, customer IDs, product catalogs, or report‑level security mappings. In such cases, the 1,000‑value ceiling becomes a hard blocker, forcing customers to redesign models, split reports, or abandon parameter‑based logic entirely. Increasing this limit would significantly improve scalability and reduce unnecessary complexity in report and model design..   Conclusion: Increasing the limit from 1000 to higher value is proposed to meet business requirements. Ref doc: Use Parameters to Visualize Variables - Power BI | Microsoft Learn  ... View more

  The show tables spark function should be lakehouse aware.  If it is without a schema, then search the root of the catalog.  If it has the schemas option enabled, then default to the "dbo" schema.  Otherwise, allow a "schema name" to be passed as an option.   A work around for now is the mssparkutils.fs.ls("Tables/Schema").  Then filter by any folder names only, these are the table directories.         Here is a screen shot for a schema less Fabric Lakehouse that works as expected.     Please fix this bug!   ... View more

We really would like the MS Fabric team to include the possibility of adding cell conditions inside the notebooks so we can decide to run or skip a cell based on the value of a parameter. Vote please! Thanks! ... View more

Need a direct option to restore deleted report in the workspace ... View more

Description: We are currently using Microsoft Fabric with Eventhouse -> Shortcut -> Lakehouse -> Snowflake Iceberg architecture. We have observed that datetime values are stored with millisecond precision (3 digits), for example: 2025-05-03 08:09:34.301 However, downstream systems like Snowflake Iceberg require microsecond precision (6 digits), such as: 2025-05-03 08:09:34.301000 This mismatch leads to compatibility issues when reading Fabric-generated Parquet files in Iceberg tables. Current behavior: Fabric stores datetime values with millisecond precision (scale 3), and there is no built-in way to enforce or convert to microsecond precision. Expected behavior: Fabric should support configurable datetime precision (e.g., 3, 6 digits) or automatically pad milliseconds to microseconds when required, ensuring compatibility with downstream systems like Iceberg. Impact: This is a critical blocker for integrating Fabric Lakehouse with modern data platforms like Snowflake Iceberg and affects enterprise adoption of Fabric in production environments.     ... View more

I've inherited some large complex Power BI semantic models that were migrated from SQL Server Analysis Services (SSAS) and many of these contain perspectives. I appreciate that they are an underused feature, but it's frustrating having to constantly switch to Tabular Editor to work with them and I'd much prefer if there was better support in both Power BI Desktop and the service for working with perspectives. We have many external customers for whom perspectives would be a good option, yet are put off when they realise they have to turn on the setting in Tabular Editor that says 'this is an unsupported feature' ... 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

Currently, Microsoft Fabric (and Power BI) does not provide a tenant setting to restrict workspace app creation to specific security groups.   The available controls are:   Workspace roles: Member role includes the ability to publish apps and manage permissions. Contributor role removes app publishing rights but also removes the ability to manage permissions on reports/models. Tenant settings: You can restrict workspace creation to specific security groups. You can control whether users can publish apps to the entire organization, but not who can create apps in general. There is no built-in setting today to allow Members to manage permissions but block app creation.   The only way to achieve this currently is: Use Contributor role for self-service workspaces (blocks app creation). Grant item-level permissions on reports/models to allow sharing without giving full Member rights.   Could I please ask for a tenant setting that would allow me to control who can create workspace apps, regardless of their workspace roles?   Thank you. ... View more

Please add an equivalent to Spark's DESCRIBE HISTORY in Fabric Warehouse which will enable us to see a list of Warehouse table versions that can be queried for time travel purposes. ... View more

It would be great to have the option to use visual calculations in card visual reference labels ... View more

Body Microsoft Fabric Data Pipelines currently expose only a binary run result (Succeeded or Failed). This works well for execution errors, but becomes limiting when pipelines are used for logical checks or validations, such as: data existence checks rule or condition evaluation control or decision pipelines In many real scenarios: the pipeline completes without execution errors, however, the evaluated logical condition is false. Today, pipeline authors must either: use Fail for expected logical outcomes (making them appear as system failures), or always return Succeeded, losing semantic meaning. Proposal Allow a pipeline run to expose an optional structured logical result (for example, enum / string / JSON), independent of execution failure. This would clearly separate: execution failure logical or validation outcome and improve observability, orchestration design, and interface clarity. Design intent This proposal does not aim to weaken or redefine execution failure semantics. Fail should remain a clear signal for true execution errors or unrecoverable exceptions. The intention is to allow pipeline executions to expose logical evaluation results without overloading failure states that are currently reserved for system-level errors, thereby reducing false failure signals in monitoring views while preserving strict execution semantics. ... View more

In enterprise environments using Dev / Prod workspaces the current 1,000 item limit per workspace becomes restrictive.   A single domain workspace for ETL activities can easily contain: Lakehouse, Pipelines, Notebooks, Dataflows   Over time, the 1,000 item limit per workspace becomes restrictive and forces teams to: Split domains across multiple ETL workspaces Introduce unnecessary workspace fragmentation Increase permission and governance complexity Add operational overhead The limit works well for small-to-medium environments, but it becomes a constraint at enterprise scale.   Suggestion: Increase the limit or Make it configurable based on capacity (F64/F128) or tenant settings This would reduce workspace fragmentation and better support enterprise-scale Fabric adoption. ... View more

Possibility for Power BI Apps to choose content across different Workspaces. ... View more

Power BI displays numbers correctly based on regional settings (e.g., comma as decimal separator), but copying values exposes the raw floating‑point value with a dot separator. Please add an option to copy the formatted (displayed) value so locale, rounding, and readability are preserved. ... View more