Is there a way to subscribe to only recent changes? I keep getting quarterly reports on things that happened 2 years ago, but I only want to see if anything has changed in the most recent quarter. ... View more

Power BI Service dynamically resizes visuals to adapt to different browsers, zoom levels, DPI scaling, and device sizes for accessibility/responsiveness. This adaptive model is valuable, but it can cause unstable rendering (“jitter”) for visuals with small multiples and dense labels (e.g., stacked bar/column charts). The result is visible reflow and re-rendering after page load or on interaction in Service, even when the layout is stable in Desktop. Microsoft’s own guidance and docs emphasize responsive behaviors for visuals (e.g., slicers and other core visuals) in both Desktop and Service, which explains why Service keeps recalculating layout for different viewports. [reddit.com], [learn.microsoft.com] Problem & impact: Unpredictable resizing in Service for stacked bar/column charts with small multiples and multiple labels/legends. Misalignment & jitter degrade trust for executive dashboards and compliance reports. Developers spend time on workarounds (fixed paddings, minimum category widths, non-auto fonts) that don’t fully prevent Service-side reflow. (These axis/padding controls exist, but they don’t stop the dynamic recalculation in Service.)  Enterprise stakeholders expect Desktop = Service consistency for sign-off; current behavior undermines that. Proposed solution: Introduce an opt-in “Lock Layout” / Pixel-Perfect Mode at the visual and/or report level that: Disables dynamic reflow in Service, preserving exact Desktop layout (fonts, paddings, grid, axis density). Caches layout once per visual load (and invalidates only on explicit user resize), rather than re-measuring labels and legends multiple times. Offers two modes for authors: Responsive Mode (current behavior; best for mobile/adaptive scenarios) Fixed Layout Mode (desktop-quality, pixel-consistent rendering for executive dashboards)   ... View more

  Problem The recent addition of Excel Drill‑Through support for Direct Lake models is a welcome improvement. However, this change introduces a significant governance and usability challenge for large enterprise models. In the current implementation: Drill‑through is enabled by default for every measure The default behavior exposes all columns from the underlying fact table The only way to control this is to manually add a detailRowsDefinition to each measure For large Direct Lake models with hundreds or thousands of measures, this is not scalable. We would prefer a governance model where drill‑through is disabled by default, and only specific, approved measures opt in. Current Pain Points To achieve controlled drill‑through today, we must: Edit every measure Add a “blocked” detailRowsDefinition for measures that should not allow drill‑through Add a custom detailRowsDefinition for measures that should allow it This is extremely time‑consuming and error‑prone at scale. Additionally, the default Excel drill‑through behavior (showing all fact table columns) is rarely appropriate for governed semantic models and cannot currently be changed. The only workaround is to: Export the model as TMDL Bulk‑edit all measures using scripts or AI Re‑import the updated TMDL This is not a sustainable long‑term approach. Requested Enhancements 1. Model‑level setting: “Disable drill‑through by default” A simple toggle in Power BI Desktop or the model properties pane that allows developers to invert the default behavior: Off by default → Measures must explicitly opt in On by default → Current behavior This would immediately solve the governance issue for large models. 2. Ability to define a default detailRowsDefinition Allow model authors to specify a default drill‑through template or suppression rule, rather than relying on the fact‑table dump. 3. Optional: UI support in Power BI Desktop For example: A model‑level drill‑through policy setting A bulk‑apply option for detailRowsDefinition A “block drill‑through” checkbox in the measure properties pane These additions would make drill‑through governance far more manageable. Why This Matters Direct Lake is designed for very large, enterprise‑scale models. These models often require strict governance, and the current drill‑through defaults create: Data exposure risks Inconsistent user experiences Significant manual overhead Providing model‑level control would align drill‑through behavior with enterprise needs and reduce unnecessary TMDL manipulation.   For reference, here’s the update announcement: Drillthrough in Excel now supported for Direct Lake and DirectQuery Models | Microsoft Power BI Blog... ... View more

Currently, we can only view email subscriptions for reports within a specific workspace. We would like an option for tenant admins to see all subscriptions across the tenant, so the admin can add or remove users and take ownership of any subscription. ... View more

Currently, when configuring Edit Interactions in Power BI reports, users must manually adjust filters and highlights for each individual visual. This process is time-consuming and prone to inconsistencies, especially in reports with multiple visuals. Proposed Enhancement: Introduce a global option that allows users to apply the same Edit Interaction settings (filter or highlight) across all visuals in a report or within a selected page ... View more

Currently, user-defined functions are defined at the model level. It would be nice to be able to define functions that are local to a DAX expression (e.g. the DAX expression of a measure, calculated column, or even a variable) so that the model-level scope does not get cluttered with functions that are needed in only a few places. This might require treating functions as first-class citizens, similar to what was done in Excel with LAMBDA, so that functions can be assigned to variables. ... View more

With the introduction of the PBIP (Power BI Project) format, Power BI has taken a huge step toward modern development workflows, including proper version control and CI/CD practices. However, today the Power BI Desktop experience still lacks native support for source control operations, forcing developers to rely on external tools such as VS Code, GitHub Desktop, or command-line Git. While functional, this breaks the development flow and raises the barrier for adoption of version control among Power BI users. Proposed idea: Developer Mode with native Git actions When a report is opened in PBIP format, Power BI Desktop could expose a new “Developer” tab in the ribbon, focused on version control and automation. This tab could offer simple, guided actions such as: View repository status (current branch, modified files) Stage changes (equivalent to git add .) Commit changes, with a popup to enter the commit message Push changes to the remote repository All actions could be implemented internally via PowerShell, which is already a first-class Microsoft technology and a natural fit for Windows-based enterprise environments. Why PowerShell? PowerShell is native to Windows and widely adopted by IT, data, and DevOps professionals It allows controlled, secure execution of Git commands It avoids the need to embed a full terminal UI, keeping the experience simple and safe Optionally, Power BI Desktop could also expose a sandboxed PowerShell console scoped to the PBIP project folder, for advanced users who want deeper automation without leaving the tool. Benefits Dramatically improves developer productivity Encourages Git adoption among Power BI users Reduces context switching between tools Aligns Power BI Desktop with modern development IDEs Complements existing Git integration in the Power BI Service / Fabric This approach keeps Power BI approachable for non-technical users while unlocking a first-class development experience for advanced and enterprise teams. Thank you for considering this suggestion. ... View more

Enable Power BI MCP server the ability to connect to Fabric Semantic Model - Direct Lake/Direct Query mode to leverage AI to improve semantic model naming and measures creation to speed up Ontology setup.  ... View more

Optimizing Data Validation in Power Query Editor with Staging Validating data in large queries within Power Query Editor can be time-consuming, as full refreshes often take a long time. Currently, developers can achieve this by creating intermediate queries or using manual workarounds, but this requires extra effort. Ideally, Power Query could provide a dedicated staging option, allowing users to mark a query as a "staging query"—similar to the existing enable/disable load feature in power query. This would let developers refresh only the staged data while keeping the main query untouched. Advantages of a staging option: Faster validation: Refresh only the staged portion of the data, saving time on large datasets. Simplified debugging: Test transformations on smaller subsets without affecting the main query. Modular workflow: Break complex queries into manageable stages with clear dependencies. Flexible development: Easily enable or disable staged queries, improving efficiency and maintainability. Adding a native staging feature in Power Query would give developers more control, reduce refresh times, and streamline the process of validating and transforming large datasets. ... View more

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

A bunch of our users were reporting cases where they are unable to Approve/Decline a report-level request when the request comes in as an email in their Outlook inbox. They are the Owner of the report, so they will receive the requests.   When they click "Approve" they are met with this error "HTTP '401'" within the email. When they attempt to open this in their browser by clicking "Manage in Power BI" it just brings them to their home page with no way to approve.      When attempting to navigate to the request under Notifications in browser, it does not lead the user anywhere either (nothing happens).       The users are Contributors to the workspace. I tested making them Members and this resolved all the above issues. They were able to approve requests within Outlook and also navigate to requests page and view the pending requests.    I'd like to contact Microsoft Power BI Support to see if this is intended or a bug.    Thank you. ... View more

“Please add back the ability to align values (center/left/right) in Matrix visuals globally under Format → Values. Currently, alignment is only available under Specific column, which makes it hard to apply consistent alignment across all value columns.” ... View more

Hi, working with warehouses often I need to view the dependencies between tables and views (but also with stored procedures and so on). Generally I query the sys.sql_expression_dependencies view, but I should be more useful a visual feature as f.e. that one of SSMS:     Work better to work less. Thanks! ... View more

Once the data model and report have been prepared for AI integration, it would be highly beneficial to implement a logging mechanism that captures user queries, Copilot’s generated responses, and corresponding user feedback (e.g., Like/Dislike). This telemetry would support iterative model refinement during the preparation process and provide valuable insights into whether Copilot is delivering accurate and contextually appropriate responses to user inquiries. ... View more

The Problem: Currently, Microsoft Fabric supports Git integration for workspace items (metadata). However, developers cannot "branch" the actual underlying data in OneLake. If a developer wants to test a new ETL logic, they must manually copy entire datasets to a "Dev" lakehouse, which is slow and consumes extra capacity. The Idea: Introduce Zero-Copy Data Branching directly within the Fabric UI. Using the power of Delta Lake’s "Time Travel," Fabric should allow users to create a "Data Branch" in a workspace. 1. Branching: A developer creates a "Dev Branch" of a Lakehouse. This creates a virtual pointer to the existing Parquet files without duplicating them. 2. Isolated Testing: The developer runs new Spark jobs or Pipelines on this branch. Only changed data is written to new files. 3. Merging: Once the code is verified, the user "merges" the data branch back to the "Main" Lakehouse, similar to a Git Pull Request for code. Why this makes Fabric better: • DevOps Excellence: It brings true "Data-as-Code" to Fabric. • Cost Efficiency: Reduces the need to store multiple physical copies of data for development and testing. • Safety: Prevents accidental corruption of production data by allowing a full "Sandbox" environment that mirrors production data perfectly.  ... View more

Add a checkbox to indicate that the schedule will never expire. Selecting this checkbox will disable the End Date field. Currently, to simulate this behavior, I have been entering “Dec 31, 9999” as the end date.   This is a simple modification that will provide greater flexibility. ... View more

Currently, scalar UDF containing non-deterministic functions (such as GETDATE) can't be used in combination in a query with a user table.   e.g. create dbo.udf () returns datetime2 as begin return getdate() end this query would fail: select col1, dbo.udf() as udf_output from usertable1 ... View more

Hello,   We use Dataflows Gen 2 to build our data transformations, and use Snowflake as our database. We run all our transformations on one single Snowflake database and try to utilize query folding as much as possible to minimize data movement. Inherently though, query folding only supports source side of the operations, and Dataflows brings the transformed, final set of data from source to its memory, only to write it back to the very same destination.   If Dataflows can distinguish it is running over a single data store/database for a set of operations, it can convert all logic to SQL (or data store's native language) and let actual execution completely happen on the database itself, preventing an unnecessary dat journey to its memory and back to the database itself.   In the past, when cloud was not a thing, we used Informatica for complete query folding (they call it push query) , and that improved ETL performance drastically.   Query folding is a great feature, and if it can cover complete DML execution on the database itself, that can bring the performance to next level.   Thank you. ... View more

Currently, I am not able to create my multi-statement table-valued functions in Fabric Warehouse and SQL anlalytics endpoint. I would like to be able to do that w/o needing to do a code change. ... View more