The data preview in the Results section of a SQL query (in either a warehouse or lakehouse) is very difficult to read as it is currently set up. It would be massively improved by implementing the following: Show the total row count at the bottom of the Results rather than just showing the row preview limit (10,000) if the actual row count goes beyond this Ideally, this would show something like Columns: 4  Rows: 56012  Rows Displayed: 10000 Allow columns in the Results to be dragged wider so it's possible to read the full column names and data As far as I can see, there's currently no way to do this in Fabric ... View more

Current behavior Today, Microsoft Fabric controls item creation through a single tenant or capacity‑level setting: “Users can create Fabric items.” This setting works on an all‑or‑nothing basis: When enabled, users can create all Fabric item types in a workspace. When disabled, users cannot create any Fabric items. There is currently no supported way to selectively allow or block specific Fabric item types (for example, allowing users to create only reports but not Lakehouses, Warehouses, Pipelines, etc.). Problem / customer impact Many organizations have strong governance and separation‑of‑duties requirements. Common scenarios include: Allowing report developers to create only Power BI reports Allowing data engineers to create data engineering objects only Preventing accidental creation of high‑impact objects (e.g., Warehouses, Lakehouses, Pipelines) Because item creation is all‑or‑nothing, admins are forced to: Over‑restrict users (Viewer role), or Over‑expose capabilities that users should not have This creates friction, governance risk, and additional administrative overhead through workarounds such as multiple workspaces per persona. Requested enhancement Provide granular creation controls that allow admins to: Enable or disable specific Fabric item types per tenant, capacity, or security group Align Fabric permissions more closely with real‑world organizational roles Improve governance without limiting adoption or usability Benefits Stronger security and governance Better role separation without workspace sprawl Reduced risk of unintentional resource creation Improved admin and customer experience ... View more

When using the Dataflow Query Execution REST API Query Execution - Execute Query - REST API (Dataflow) | Microsoft Learn queries are terminated after ~90 seconds.   This fixed timeout significantly limits real‑world usage. Only very small or simplified queries can be executed, while more complex or parameterized queries (although valid and supported in normal Dataflow refreshes) are cancelled. This limitation makes it difficult to: Build generic or reusable Dataflow solutions Execute dynamic or complex queries via automation Use the API consistently compared to pipelines Suggested improvements: Increase the default timeout Make the timeout configurable   Many users aim to build generic, reusable, and automated Dataflow solutions in Fabric. The current timeout makes this difficult and forces unnecessary workarounds, such as: Over‑splitting queries Avoiding the API altogether Falling back to less flexible execution methods Improving this would unlock significantly more value from the Dataflow Query Execution API. ... View more

Currently, the “Apply to entire organization” option is not enabled in Copilot Capacity Settings. As a result, to restrict Copilot CU usage to a specific capacity, administrators are required to create and maintain a group that includes all users in the organization. From an admin and UX perspective, this introduces unnecessary overhead and ongoing maintenance. Enabling the “Apply to entire organization” option would significantly simplify configuration, reduce operational effort, and improve the overall administrator experience. I’ve already discussed this topic with the PM responsible for Power BI Copilot, and I understand the design considerations behind the current approach. That said, I would like to encourage the team to reconsider the factors leading to this restriction, as the current setup adds complexity without clear value for administrators. Allowing Copilot to be applied to the entire organization at the capacity level would be: Easier to configure Easier to govern Less error‑prone More intuitive for Fabric administrators I hope other Fabric admins find this improvement valuable and can vote to support this idea. Thank you for considering this feedback. ... View more

Fabric notebooks run inside a managed execution environment that includes built‑in libraries, system packages, runtime versions, and environment bindings. Today, there is no external API that exposes these built‑in resources for a given notebook. While the existing Fabric REST APIs support CRUD operations and job scheduling, they do not provide visibility into the runtime resources that a notebook depends on. This creates gaps in automation, governance, reproducibility, and environment transparency. This feature request proposes a Notebook Resources API that allows programmatic access to the full resource profile of a notebook. In more simpler words, this picture tells you exactly what items the api should retrieve.   ... View more

Today, Workspace Monitoring is configured separately per workspace, which introduces maintenance overhead and likely also a repeated baseline CU cost for each workspace.   Please make it possible to create Workspace Monitoring instances that cover multiple workspaces.   Users should be able to decide how many monitoring instances to configure and which workspaces each instance covers.   This would allow the baseline monitoring cost to be shared rather than incurred separately per workspace, reducing overall cost while also simplifying configuration and ongoing maintenance. In addition, it would enable a more centralized and flexible monitoring setup across workspaces. ... 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

When a scheduled refresh completes with warnings such as "Cannot convert value 'xx' of type Text to type Number", the warning message in refresh history does not include the table name and column name where the issue occurred. Data refresh in Power BI - Power BI | Microsoft Learn To enable all users to easily investigate the root cause of the warning, please include the affected table name and column name in the refresh history warning message. ... View more

  Description / Problem Our organization has fully enforced phishing‑resistant authentication methods for all employees and administrative accounts, in line with Microsoft security best practices. These include passkeys and FIDO2 hardware security keys (for example, YubiKey). However, we currently need to maintain Power BI on‑premises data gateway (February 2026 version) as an exception to these policies. The reason is that the embedded web authentication engine used by the gateway does not support FIDO2 authentication. Because of this limitation, we are unable to enforce phishing‑resistant authentication methods for gateway sign‑in and administration. Current Behavior The Power BI on‑premises data gateway currently supports: Password‑based authentication, or Passwordless authentication using number matching While number matching improves security, it does not meet the definition of phishing‑resistant authentication required by many enterprise security and compliance standards. Impact Forces organizations to maintain authentication exceptions Creates a security gap in otherwise fully phishing‑resistant environments Prevents full alignment with Zero Trust and passwordless‑first strategies Affects enterprises with strict regulatory, compliance, or security mandates Requested Enhancement Please add FIDO2 authentication support (passkeys and hardware security keys) to the Power BI on‑premises data gateway in a future update. This would allow organizations to: Fully enforce phishing‑resistant authentication across all Fabric and Power BI components Eliminate password‑based authentication for gateway administration Align the gateway with Microsoft’s broader identity and security roadmap ... 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

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

Hello. Could you add an "Ends with" filter option, in the advanced options of the filter menu, just like in Excel : Hopefully this is understandable, I'm not sure of the names in english. Thank you. ... View more

We have been observing that Power BI semantic models are automatically triggering a refresh immediately after being republished to the Power BI Service. In the refresh history, this is tagged as "On-demand", even though no manual action was performed. Upon reaching out to Microsoft, we received the following confirmation: “This is the expected behavior from the Power BI Service once a semantic model is republished. The behavior is by design and applies to all semantic models in Import mode (or those using auto-aggregations). This behavior has been consistent for several years, and there are currently no plans to change it in the product roadmap.”   While this behavior can be beneficial in certain scenarios—particularly for smaller models that complete refreshes within seconds—it introduces challenges in the following cases: Incremental Refresh Models:  In some situations, the refresh may process more data than expected, leading to longer execution times. Large or Complex Models: Models with sizes exceeding 5–10 GB or with high complexity may require several minutes to refresh, increasing resource consumption.   This behavior can significantly impact capacity resources, especially in Fabric capacity-enabled workspaces, where such unintended refresh activity may lead to unnecessary resource utilization and potential performance issues.   It would be highly beneficial if this behavior could be controlled at the user level or at least at the tenant level, allowing organizations to prevent unintended refreshes and better manage capacity consumption. ... 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

Power BI and Microsoft Fabric currently do not offer a tenant‑level or portal‑wide banner capability that allows administrators to proactively notify all users when data is stale, delayed, or impacted by upstream system failures. In real‑world enterprise environments, pipelines, dataflows, and semantic models frequently depend on external source systems. When these sources are unavailable or delayed, reports may continue to load successfully but display outdated data, creating a silent failure scenario. Users have no visible indication that the information they are viewing may not be reliable. Today, administrators lack a centralized, in‑product mechanism to communicate these conditions to all users at the moment they access Power BI / Fabric. ... View more

The Problem Currently, when a Semantic Model refresh in Fabric/Power BI becomes unresponsive—often due to "zombie" queries on the source system, gateway bottlenecks, or locks on external data sources—the "Cancel" command is merely a request, not a command. As per Microsoft Support, the service waits for a "safe point" or an atomic commit before stopping. However, in many real-world scenarios, the refresh enters a "stuck" state that never reaches a safe point, forcing developers and capacity admins to wait for the 5-hour hard timeout. The Impact Capacity Waste: A "stuck" refresh continues to consume CU (Capacity Units) and memory for hours, unnecessarily inflating costs or throttling other critical workloads. Development Downtime: Developers are blocked from re-triggering a corrected refresh until the "stuck" one clears. Operational Risk: If a refresh is hogging a gateway or source connection, it can cause a "logjam" effect for all other scheduled items in the tenant. The Current "Workarounds" are Non-Viable Microsoft Support often suggests restarting the On-premises Data Gateway or reassigning the Workspace Capacity to kill a stuck process. However, these are not feasible solutions in a production environment because: Collateral Damage: Restarting a gateway or shifting capacity kills every other active refresh and connection in that environment. Service Interruption: It causes a cascade of failures for critical reports that are otherwise running perfectly, leading to widespread business disruption just to stop one "zombie" process. Administrative Overhead: It requires high-level permissions and causes manual cleanup work for admins across the entire tenant. The Proposed Solution: The "Force-Kill / Discard Shadow" Switch Since Power BI/Fabric utilizes a "copy-on-write" approach—where a new version of the model is constructed in the background while the original remains available for queries—there is a logical path for a forced interruption: Discard Shadow State: Introduce a "Force Kill" option that immediately terminates the Service’s tracking of that specific Refresh ID. Immediate Resource Release: Rather than waiting for the external query to return or the "commit" phase, the Service should immediately stop billing CUs for the process and mark the background "shadow" model for deletion. Source Termination: Trigger a "Cancel" signal to the Data Gateway or the SQL/Data Lake source to attempt to kill the session at the source, but do not make the Service wait for confirmation from the source before releasing the Fabric Capacity. The Argument: Data Integrity is Not at Risk The standard justification for this delay is "maintaining data integrity." However, Power BI/Fabric utilizes a shadow-refresh (copy) mechanism. Since the refresh is building a new version of the model in the background while the original remains live for users: Force-killing the refresh should simply discard the background shadow copy. The original model remains untouched, so no data corruption can occur. There is no logical reason to wait 5 hours to "safely" discard a model that is already failed/stuck. Why this is feasible: Because the original dataset remains untouched until the very final "commit" phase, "killing" a refresh during the processing phase should carry zero risk of data corruption to the live model. We are simply asking for the ability to "toss out the draft" immediately rather than waiting 5 hours for the draft to realize it's stuck. Conclusion In the era of Fabric's "Pay-as-you-go" and "Capacity-based" pricing, being forced to pay for 5 hours of a stuck refresh is a significant pain point. We need a "Kill Switch" that prioritizes Capacity Governance over "Waiting for a safe point" when the developer knows the refresh is already a failure.   #Semantic Model, #Capacity Management, #Developer Experience, #Refresh. ... View more

Live embedded reports maintain state in PowerPoint. When changes are made to the report (such as adding new slicers), the embedded session may not fully isolate page-level visuals, causing slicers to appear unexpectedly.  ... View more

When exporting data from Power BI using “Summarized data (.xlsx with live connection)”, the resulting Excel file does not inherit the sensitivity label applied to the dataset or report, even when the tenant setting “Automatically apply sensitivity labels to downstream content” is enabled. This behavior creates a potential data leakage risk, as file‑level protection controls are not enforced on the exported Excel file.   Expected Behavior: Automatically apply the dataset/report sensitivity label to Excel files created using Summarized data (.xlsx with live connection) OR Clearly document and surface warnings in the export UI indicating that this export option does not support sensitivity label inheritance ... View more

The current card visual forces users to overlap elements or waste copious amounts of time creating custom visuals. The new card feature should give users the ability to create multiple cards in a single container and provide a greater level of customization. ... View more