New idea exchange ideas in Microsoft Fabric Community

Allow External OneLake Data Shares to Be Accepted into Multiple Fabric Item Types

Mourak — Sat, 29 Aug 2026 08:25:19 GMT

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

Mourak — Sat, 29 Aug 2026 08:24:18 GMT

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.

Tenant-Wide OneLake Shortcut Lineage and Impact Analysis

Mourak — Sat, 29 Aug 2026 08:18:41 GMT

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.

Add an End-to-End Production Reference Architecture for Microsoft Fabric Real-Time Intelligence

Mourak — Sat, 29 Aug 2026 08:12:29 GMT

I would like to see a complete end-to-end Microsoft Fabric Real-Time Intelligence reference architecture that demonstrates how the individual RTI capabilities work together in a production-oriented solution.

A manufacturing or operational telemetry scenario could show the complete flow from Eventstream through Eventhouse and KQL, Real-Time Dashboards, Activator, Power BI, Fabric Data Agents, and other applicable Microsoft Fabric capabilities.

The guidance should explain architectural responsibilities, latency and retention choices, schema evolution, replay, security, governance, monitoring, CI/CD, environment promotion, connection management, and troubleshooting.

It would also be valuable to explain when deterministic KQL queries, rules, or Activator actions should be used before introducing AI or agent-based processing.

This would help architects, developers, students, and community learners understand how to move from individual Fabric RTI features to a governed and production-ready real-time solution.

Improve CI/CD consistency for Microsoft Fabric Real-Time Intelligence Eventstreams

Mourak — Sat, 29 Aug 2026 08:11:33 GMT

Microsoft Fabric Real-Time Intelligence has made strong progress with Git integration and deployment pipelines, but lifecycle management can still be inconsistent across Eventstream sources, destinations, connections, and deployment scenarios.

I would like to see more consistent CI/CD support across Real-Time Intelligence artifacts, including automated environment-specific connection rebinding, easier promotion from development to test and production, deployment validation before activation, and clearer diagnostics when an RTI artifact cannot be promoted successfully.

For enterprise implementations, it would also be valuable to reduce the amount of manual reconfiguration required after deployment.

Improving these capabilities would make Real-Time Intelligence solutions easier to operationalize, govern, automate, and teach as production-ready architectures rather than solutions that require manual configuration between environments.

The Power BI app is having issues on Android

minhtai — Sat, 29 Aug 2026 03:14:50 GMT

Issue Report – Power BI Android App

The Power BI app on Android has been experiencing an issue since yesterday morning and is still not working properly today.

- Platform: Android

- App: Microsoft Power BI

- Issue: Reports cannot be loaded/accessed in the Power BI app.

- Duration: From yesterday morning until today.

- Additional information: The same Power BI reports work normally when accessed via Samsung Internet on the same device.

Please help investigate and resolve this issue as soon as possible.

Collections in PowerBI

jschlereth2 — Fri, 28 Aug 2026 15:42:28 GMT

Allow all users to create "collections" in Power BI...folders where they can organize dashboards they have access to in order to provide more personal clarity where things are located at.

One of the biggest challenges we have is users remembering what specific workspace dashboards are saved in. This would be mitigated if Power BI made it so users can create their own folders to organize dashboards according to their own mental model rather than trying to adopt/remember the mental model provided by the central team. This is akin to knowing someone else's folder structure rather than one's own folder structure.

This would not be intended to change access at all, just would be an organizational structure for the individual.

Display Delta table and column descriptions in Fabric Lakehouse Explorer/ Fabric on Browser

Darsh_ — Fri, 28 Aug 2026 14:20:03 GMT

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.

Support Cross-Tenant (B2B/MTO Member) Authentication for Fabric Data Warehouse in Power BI Desktop

v-nandagm — Fri, 28 Aug 2026 09:54:44 GMT

Microsoft Fabric Data Warehouse SQL Endpoints currently do not support cross-tenant authentication scenarios when accessed from Power BI Desktop. While B2B/Multi-Tenant Organization (MTO) member users can successfully access Fabric artifacts through the Fabric Service portal after switching to the target tenant, the same users are unable to authenticate when connecting to the Warehouse SQL Endpoint from Power BI Desktop using the Azure SQL Database connector.

Kindly support Cross-Tenant (B2B/MTO Member) Authentication for Fabric Data Warehouse SQL Endpoint in Power BI Desktop

Hide tabs in embedded Paginated report.

VineetPai — Fri, 28 Aug 2026 05:33:37 GMT

Whenever a paginated report is embedded into an application it displays two tabs by default. One tab consists of options File,Home,View and another tab consists of Export options.

Currently there exists no option to hide these tabs neither from the code end nor from the PowerBi report builder. Hence the ask would be to hide these tabs in a configurable way.

Power BI Report Builder - Difficult to Use and Ugly.

rs_rae — Fri, 28 Aug 2026 00:45:28 GMT

So I've definitely been spoiled in the modern age. So many apps that are integrated well with top-notch UI, and intuitive processes. Power BI Report Builder is surprisingly lacking in this. While I am grateful for the monthly updates to Power BI, the Report Builder is not easy to use at all.

I feel like there should be a much more intuitive integration between the two - i.e., be able to take a page from a Power BI Report, and "export" it to Power BI Report Builder, with all the filters, visuals, and settings etc in there. Realistically, as the user, I think it makes sense for it to all be in one program. I was actually really surprised to find out that it was a separate program that I was supposed to use for making pdfs etc.

My current workaround is building the model in Power BI, publishing it, and then using Get Data > from Power BI in Excel to get the data. And then building it in Excel... because Power BI Report Builder feels so unintuitive. And yes, we will always need paginated reports... right now I guess we are stuck with the many tabs in Excel.

I might try to use Power BI Report Builder again, but it feels like I'm stepping into the 2000s with its appearance and feel. And the fact that I have to recreate everything is so odd, it really is surprising that you can't easily add this sort of thing to Power BI itself, even just adding page breaks and better exporting to PDF to PBI would help so much with our actual business use cases. Everyone just asks for PDF versions of the dashboards anyways.

Individual L/R column borders for Matrix

AaronReasoner — Thu, 27 Aug 2026 21:06:38 GMT

Add Power BI feature for applying left and/or right borders to individual matrix columns, with customizable border thickness and color. This would let users visually group related measures, highlight key sections, and create cleaner, executive-friendly report layouts.

Consistent Locale Handling Across Power BI, Fabric, PowerPoint, and Subscriptions

Le_M — Thu, 27 Aug 2026 15:03:16 GMT

Microsoft Fabric and Power BI should provide consistent locale handling across all user experiences. Today, locales such as German (Switzerland) are correctly respected in Power BI Desktop and the Power BI Service, but not in PowerPoint live embedding and subscription emails, where number and date formats can differ.

This issue likely affects other languages and regional settings as well. Locale preferences should be applied consistently across all integrations and output channels to ensure a seamless user experience.

Consistent locale handling is imperative for usability, trust, and adoption in international organisations. Users must be able to rely on the same number and date formats regardless of where Power BI content is consumed. Microsoft's localisation strategy should be implemented end-to-end across the entire platform.

Power BI Admin & Governance Center – Centralized Activity and Usage Analytics

Dr7awb — Thu, 27 Aug 2026 09:45:31 GMT

Subject: Feature Proposal: Advanced Power BI Admin & Governance Center – Centralized Activity, Access, Sharing, Licensing and Usage Analytics

Dear Microsoft Power BI Team,

I would like to propose a comprehensive enhancement to the Power BI administration experience: an Advanced Power BI Admin & Governance Center that provides administrators with a centralized view of users, workspaces, reports, pages, sharing, permissions, licensing, dependencies, and activity.

Today, administrators often need to navigate multiple areas of the Power BI Service, workspaces, sharing settings, APIs, audit logs, and Microsoft administration portals to answer basic governance questions. A centralized governance experience would significantly improve visibility, security, auditing, and operational efficiency.

1. Complete User Activity

Provide administrators with detailed visibility into who accessed what, when, and how frequently.

Workspace activity

User who accessed the workspace
Date and time
Activity type
Last access
Access frequency

Report activity

User who opened the report
Date and time
Number of views
Last viewed
Access method

Report page activity

Specific page viewed
User who viewed it
Date and time
Number of views
Last viewed

For example:

User: Ahmed Workspace: Clinical Analytics Report: OP Performance Page: Surgery Performance Opened: 27 Aug 2026 – 08:42 AM

This should allow administrators to answer:

Who opened what, when, and how frequently?

2. Centralized Sharing & Access Intelligence

Provide one centralized view of all sharing and access relationships.

For each workspace, report, and relevant artifact, administrators should be able to see:

Who has access
How access was granted
Direct user access
Security group access
Shared link access
Workspace membership
App access
Viewer / Contributor / Member / Admin role
Date access was granted
Last access
Whether the access is actively being used

For example:

Report: Executive Dashboard Shared By: Ahmed Shared On: 27 Aug 2026 – 09:15 AM Shared With: Group COO Access Type: Specific people Permission: View

For broader sharing:

Access Type: Anyone in organization Risk: High

Power BI could also provide governance alerts for potentially excessive or risky access.

3. “Who Has Access To What?” — Central Access Matrix

Provide an administrator-wide access matrix instead of requiring administrators to inspect each workspace and report individually.

User	Workspace	Report	Page	Access Method	Role
User A	Finance	Revenue	Overview	Workspace	Viewer
User A	Clinical	OP Dashboard	Surgery	Direct	Viewer
User B	Finance	Revenue	—	Security Group	Member
User C	Executive	CEO Dashboard	KPI	Shared Link	Viewer

The matrix should support filtering by:

User
Workspace
Report
Semantic model
Security group
Access type
Role
Last accessed date

This would make access reviews, permission audits, and compliance investigations substantially easier.

4. License & User Status

Provide a centralized view of the licensing state and actual Power BI utilization of every user.

Include:

Power BI Pro
Power BI Premium Per User
Fabric license
Free license
Trial status
Trial expiration date
License assignment date
Last Power BI activity
License utilization
Potential license reclaim candidates

For example:

Ahmed Power BI Pro Active Last Activity: Today User B Power BI Pro Inactive for 120 days Potential license reclaim User C Free Fabric Trial Trial expires: 14 Sep 2026

Power BI could also provide actionable alerts such as:

12 users have Pro licenses but have not used Power BI in 90 days.

This would allow organizations to optimize license allocation based on actual usage rather than assignment alone.

5. Semantic Model Dependency View

Because multiple reports can depend on the same semantic model, administrators should have a centralized dependency view.

For example:

Semantic Model

│

├── Report A

│

├── Page 1

│

└── Page 2 │

├── Report B

│

├── Page 1

│

└── Page 2

│

└── Report C

└── Page 1

Administrators should be able to immediately determine:

Which reports use a semantic model
Which workspaces contain those reports
Who has access
Who actually uses them
Refresh status
Last successful refresh
Report usage
Page-level usage where available

This would be particularly valuable when assessing the impact of changes to a shared semantic model.

6. Power BI Administrator vs. Tenant-Level Visibility

Power BI administrators should have the necessary Power BI governance visibility without automatically requiring unrelated Microsoft 365 or Azure administrative privileges.

In other words:

Being a Power BI Administrator should provide the necessary permissions to perform Power BI governance without requiring broader Microsoft 365 administrative privileges.

Where additional permissions are genuinely required, Power BI should explicitly identify the missing permission.

For example:

Additional Permission Required: Microsoft Entra Global Administrator

Rather than simply hiding the information or returning an ambiguous access-denied result.

This would make the administration model significantly more transparent.

7. Centralized Power BI Governance Dashboard

The Admin Center could provide a single governance dashboard containing:

Users

Total users
Active users
Inactive users
Licensed users
Trial users

Workspaces

Total workspaces
Active/inactive workspaces
Workspace owners
Members
Orphaned workspaces

Reports

Total reports
Most viewed reports
Never-viewed reports
Last viewed
Reports with no recent activity

Access

Users with broad access
Shared links
External sharing
Direct permissions
Security-group permissions

Licensing

Pro utilization
Trial users
Unused licenses
Expiring trials

Activity

Most active users
Most accessed workspaces
Most viewed reports
Most viewed pages

8. Governance Search

A particularly useful capability would be a global governance search.

An administrator could search for:

Ahmed

and immediately see:

Ahmed

│

├── Licenses

│

└── Power BI Pro — Active

│

├── Workspaces

│

├── Clinical Analytics — Member

│

└── Executive Analytics — Viewer

│

├── Reports

│

├── OP Performance

│

└── Executive Dashboard

│

├── Recent Activity

│

└── Last activity: 27 Aug 2026

│

└── Shared Access

└── Executive Dashboard → Group COO

Likewise, an administrator could search for a report, workspace, semantic model, or security group and immediately understand its complete governance footprint.

Core Principle

The administrator should be able to answer the following questions from one place:

Who has access to what?
Who actually uses it?
Who opened it and when?
Which report and page did they open?
Who shared it?
When was it shared?
Who received the access?
Which workspaces and reports use this semantic model?
Does the user have a license or trial?
Is that license actually being used?
What Power BI permissions are required to see or manage this information?

The goal is not simply to provide better activity logs. It is to establish a centralized governance layer for Power BI that combines activity, access, sharing, licensing, dependencies, and usage analytics into a single administrative experience.

This would be particularly valuable for enterprise organizations that need to perform regular access reviews, license optimization, compliance audits, security investigations, and impact analysis across large Power BI environments.

Suggested Power BI Idea Title:

Advanced Power BI Admin & Governance Center – Centralized Activity, Access, Sharing, Licensing and Usage Analytics

Best regards,
Ahmed Albukhaytan

Feature Proposal: Expandable/Collapsible Page Sections for Reports on Same Semantic Model

Dr7awb — Thu, 27 Aug 2026 09:42:03 GMT

Subject: Feature Proposal: Expandable/Collapsible Page Sections for Reports Using the Same Semantic Model

Dear Microsoft Power BI Team,

I would like to propose an enhancement to the Power BI report navigation experience: expandable/collapsible page sections with shared semantic model-based navigation.

This would be particularly valuable in enterprise environments where multiple reports are built on the same semantic model but serve different purposes, departments, or audiences.

1. Expandable/Collapsible Page Sections

Allow report authors to organize pages into logical sections within the report navigation.

Key capabilities could include:

Create expandable/collapsible sections in the report navigation.
Group related pages under logical sections.
Set sections as expanded or collapsed by default.
Drag and drop pages between sections.
Reorder sections and pages.
Collapse sections to reduce navigation clutter.
Easily manage large reports containing dozens of pages.

For example:

📊 Executive

├─ Executive Overview

└─ KPI Summary

🏥 Operations

├─ OP Performance

├─ IP Performance

└─ Surgery

💊 Pharmacy

├─ Sales

├─ Inventory

└─ Controlled Medications

📈 Financial

├─ Revenue

└─ Cost Analysis

This would provide a much cleaner navigation experience than having every page displayed at the same level.

3. Benefits for Enterprise Reporting

This capability would be particularly useful for organizations with:

Large numbers of Power BI reports.
Multiple reports connected to centralized enterprise semantic models.
Department-specific reporting requirements.
Executive, operational, financial, and clinical reporting layers.
Large reports containing many pages.

Instead of forcing users to navigate through dozens of pages or maintain complex collections of navigation buttons, Power BI could provide a structured hierarchy that is easier to understand and maintain.

Suggested User Experience

The sections could be collapsed or expanded based on the user's preference, significantly reducing navigation clutter.

Core Principle

The goal is to provide hierarchical navigation at the report level.

Suggested title:

Expandable/Collapsible Page Sections

Best regards,
Ahmed Albukhaytan

Feature Proposal: Fault-Tolerant Refresh, Schema Changes & Intelligent Retry

Dr7awb — Thu, 27 Aug 2026 09:24:11 GMT

Subject: Feature Proposal: Fault-Tolerant Refresh, Schema Changes & Intelligent Retry

Dear Microsoft Power BI Team,

I would like to propose an enhancement to Power BI semantic model refresh behavior focused on schema changes, dependency awareness, and intelligent recovery.

A source schema change should not automatically result in a failed refresh. Power BI should first evaluate whether the change actually affects the semantic model or any downstream logic.

1. Intelligent Schema Change Handling

When a source column is missing, renamed, or changed, Power BI should analyze its dependency before failing the refresh:

Column is not referenced anywhere: Continue the refresh normally and display a warning.
Column is referenced but has no meaningful downstream dependency: Continue with a warning and identify the affected column.
Column is required by a Power Query transformation: Attempt intelligent recovery/retry before failing.
Column affects a downstream transformation, measure, relationship, or visual: Clearly identify the dependency and explain the specific impact.

The objective is to distinguish between a harmless schema change and a change that genuinely breaks the model.

2. Special Handling for Changed Type

One particularly common scenario occurs when a source column is removed but Power Query still references that column in a Changed Type step.

For example:

Source ↓ Column A Column B ← Removed from source Column C ↓ Changed Type ↓ Filter ↓ Merge ↓ Output

If Column B is only referenced by the Changed Type step and is not used by any subsequent transformation, Power BI should recognize that the missing column does not affect the resulting query.

Instead of failing the refresh, Power BI could provide:

Warning: Column Column B is no longer available in the source. The column is only referenced by the Changed Type step and has no downstream dependency. Refresh continued successfully.

Ideally, Power BI could automatically:

Ignore the missing column in the Changed Type step, or
Retry the query with the obsolete type transformation removed, without requiring the developer to manually modify the M code.

3. Dependency-Aware Backend Recovery

Power BI could introduce an automatic recovery mechanism based on the dependency graph:

Refresh → Detect Error → Analyze Dependency → Determine Impact → Apply Safe Adjustment → Retry → Continue

For example, if the only failure is a missing column referenced by Changed Type, Power BI could safely exclude that column from the type transformation and retry the query.

The recovery should only be applied when Power BI can establish that the adjustment is semantically safe and does not affect downstream results.

4. Refresh Status

The refresh result should clearly distinguish a successful refresh with a non-critical schema warning from an actual failure.

For example:

🟢 Updated with Warning — 100% Complete
1 source column missing: Column B
Column is not used by downstream transformations.
Refresh completed successfully.

Instead of:

🔴 Refresh Failed

The warning should remain visible in the Power BI Service refresh history so administrators can identify and investigate schema changes without unnecessarily treating them as failed refreshes.

5. Dependency Impact Reporting

For columns that are genuinely required, Power BI should provide a precise dependency explanation rather than a generic error.

For example:

🔴 Refresh Failed — Required Column Missing
Missing column: Column B
Used by: Filter Rows → Merge Queries → Final Output
Impact: Query cannot be safely recovered automatically.

This would significantly reduce troubleshooting time by showing where the missing column is actually required.

6. Core Principle

The key principle should be:

A schema change should not automatically equal a refresh failure.

Power BI should evaluate the dependency impact first:

Missing & unused → Warning + Continue

Missing but safely recoverable → Auto-adjust/retry + Warning

Missing & required → Dependency-aware retry → Fail with precise explanation

This would make Power BI refreshes substantially more fault-tolerant and resilient, particularly for enterprise semantic models connected to large external databases where source schemas can evolve over time.

A harmless column removal should not bring down an otherwise healthy dataset, while genuinely breaking schema changes should still be surfaced clearly and accurately.

Best regards,
Ahmed Albukhaytan

Fault-Tolerant Table-Level Refresh, Retry & Completeness Monitoring

Dr7awb — Thu, 27 Aug 2026 09:22:50 GMT

Subject: Feature Proposal: Fault-Tolerant Table-Level Refresh, Retry & Completeness Monitoring

Dear Microsoft Power BI Team,

I would like to propose an enhancement to the Power BI semantic model refresh experience, particularly for large enterprise models that depend on gateways, external databases, and complex Power Query transformations.

1. Table-Level Refresh

Allow individual tables/queries within a semantic model to refresh independently rather than treating the entire dataset as a single refresh operation.

Each table/query should refresh independently.
A failed table should not prevent other tables from successfully refreshing.
Successfully refreshed tables should become available immediately.
If a table fails, Power BI should retain and continue serving its last successfully refreshed data.

2. Automatic Retry

Power BI should provide configurable retry behavior for transient failures such as timeouts, temporary connection issues, or gateway interruptions.

Suggested options:

Retry immediately
Retry after a configurable delay, such as 5, 15, 30, or 60 minutes
Configure the maximum number of retry attempts
Provide a Retry Now option for individual failed tables

3. Refresh Status

The Power BI Service should provide clear status visibility at both the overall dataset level and individual table level:

🟢 Updated / Current
🔵 Refreshing
🟡 Retrying
🟠 Partially Updated
🔴 Failed
⚪ Not Refreshed

4. Refresh Completeness

Introduce a Refresh Completeness % indicator showing how much of the semantic model has successfully refreshed.

For example:

Refresh Completeness: 92%
23 of 25 tables successfully refreshed.

It would also be valuable to distinguish between critical and non-critical tables, allowing organizations to define which tables are essential for the model to be considered fully operational.

Table	Status	Last Successful Refresh	Completeness
Patient Encounters	Current	Aug 27, 08:05	100%
Pharmacy Sales	Current	Aug 27, 08:07	100%
Surgery	Retrying	Aug 26, 08:02	Previous Data
Billing	Failed	Aug 26, 08:10	Previous Data
Inventory	Current	Aug 27, 08:09	100%

5. Stale Data Transparency

If a table cannot be refreshed, Power BI should continue using its previous successful data rather than making the entire semantic model unavailable.

However, users should be clearly informed that the data is stale, for example:

⚠️ Previous Data — Last Updated Aug 26, 08:10

This would provide a much better balance between availability and transparency. Reports could remain operational while users are clearly informed which data is not current.

6. Detailed Refresh Progress in Power BI Service

The online refresh experience would also benefit from real-time, table-level execution visibility, including:

Current table/query
Current Power Query transformation/step
Rows processed
Elapsed time
Estimated remaining time
Source execution time
Power Query/Mashup execution time
Data loading time
Retry count
Next retry time
Detailed error information
Last successful refresh
Overall refresh completeness %

Ideal Overall Status

Instead of displaying only:

❌ Refresh Failed

Power BI could provide an operationally meaningful status such as:

🟠 Partially Updated — 92% Complete
23/25 tables updated successfully
1 table retrying • 1 table using previous data
Next retry: 10 minutes

This approach would make Power BI semantic model refreshes significantly more resilient, transparent, and operationally useful, especially for large enterprise environments where a single transient failure, timeout, gateway issue, or external database problem should not invalidate an otherwise successful refresh.

I believe this would be a valuable enhancement for enterprise Power BI customers and would significantly improve the reliability and observability of production semantic models.

Best regards,
Ahmed Albukhaytan

Allow Measures to Be Grouped/Categorized in Matrices and Tables

Dr7awb — Thu, 27 Aug 2026 09:02:27 GMT

Introduce the ability to group and categorize measures directly within Matrix and Table visuals, allowing report developers to organize large sets of measures into logical sections or expandable categories.

This would improve readability, navigation, and user experience, particularly for reports containing a large number of KPIs and calculated measures.

Example:

Financial KPIs
- Revenue
- Gross Margin
- Net Profit
Operational KPIs
- Patient Volume
- Waiting Time
- Utilization
Quality KPIs
- Readmission Rate
- Patient Satisfaction
- Mortality Rate

Ideally, categories should support expand/collapse functionality and be configurable directly within the visual, without requiring additional model tables or complex workarounds.

Make workspace and item session persistence optional

TeemuMultanen — Thu, 27 Aug 2026 08:07:49 GMT

Description

The new persistent session behavior in Microsoft Fabric should be optional rather than forced.

Currently, Fabric remembers the workspaces and items that were open in my previous session. When I close the browser and later return to Fabric, those items are restored automatically.

I would like an option to completely disable this behavior.

When I close my browser, I consider that session finished. The next time I open Fabric, I want to start with a clean session with no previously opened workspaces or items restored.

This would also make it easier to use separate browser tabs or windows for different tasks. For example one tab for notebooks, pipelines, and lakehouses related to specific data source and another tab for resources related to another source. Persisting and restoring the previous Fabric session makes it harder to compartmentalize work this way.

I understand that session persistence can be useful for users who want to continue exactly where they left off, so I am not suggesting that the functionality should be removed.

Instead, please provide a user preference such as:

Restore previous Fabric session

On – Restore previously open workspaces and items
Off – Start with a clean Fabric session

When this setting is disabled, closing the browser should effectively end the Fabric UI session. Opening Fabric again should start fresh without restoring previously opened workspaces, items, or tabs.

Why this matters

The current behavior can make Fabric slower and more cumbersome for users who frequently multitask across workspaces and different Fabric experiences.

A persistent session is useful when you intentionally want to continue working later. For users who prefer a clean workspace after closing the browser, however, it should be opt-in rather than mandatory.

Allow report creators to download their Own PBIX even when Downloads are restricted at tenant level.

pbiuserNC — Wed, 26 Aug 2026 19:10:28 GMT

In the current Power BI permission model, PBIX downloads are controlled exclusively through tenant‑level export settings and workspace roles. This creates a significant limitation for multi‑agency or large enterprise environments: enabling PBIX downloads grants broad download access to any user with Contributor permissions in any workspace, regardless of whether that user originally authored the report.

What’s missing:
Power BI has no concept of “author-level” permissions for published reports. Although the service identifies report contacts and retains semantic model owners for refresh purposes, these fields are not tied to download rights. As a result, report creators cannot download their own PBIX files unless they are manually added to security groups or privileged roles — even when they are the sole developer and publisher of that content.

Why this matters:
Organizations with strict governance requirements need a middle-ground option that allows report creators to retrieve their own work without exposing underlying datasets broadly across their tenant. Today, the only choices are:

Turn PBIX downloading off entirely, or
Turn it on for specific security groups (which often include far more users than just the report authors).

This limits flexibility, complicates content lifecycle management, and increases administrative overhead.

Requested enhancement:
Introduce an “owner-only PBIX download” permission that allows the original report creator (or designated report contact/semantic model owner) to download the PBIX file even when global download settings remain restricted.
This would enable organizations to give creators access to their own work without expanding download rights for all Contributors.

Benefits:

Restores creator-level autonomy without compromising data security
Reduces administrative overhead for tenants with many workspaces or agencies
Provides the exact middle-ground scenario many customers need
Aligns Power BI’s ownership model with user expectations in other Microsoft tools

Optional implementation ideas:

A per‑report toggle: “Allow report creator to download PBIX”
A workspace setting: “Creators may download PBIX regardless of tenant-level restrictions”
Linking download rights to the report contact field or semantic model owner