New idea exchange ideas in Microsoft Fabric Community

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

Native KPI Governance, Ownership and Business Change Impact in Microsoft Fabric

kulkarnigauri3 — Wed, 26 Aug 2026 14:48:03 GMT

Native KPI Governance, Ownership and Business Change Impact in Microsoft Fabric

Idea

In enterprise analytics, one of the biggest challenges is not creating a KPI, but ensuring that everyone agrees on what that KPI means and continues using the same definition across reports, semantic models, scorecards, and teams.

I would like to see Microsoft Fabric provide a native KPI governance and business change management capability that connects business definitions directly with the underlying semantic model and downstream reporting assets.

For each governed KPI or business metric, organizations could maintain:

Business definition
Business owner / data steward
Technical owner
Semantic model measure or calculation
Data source and grain
Business rules and exclusions
Target or threshold
Refresh frequency
Certification status such as Draft, Reviewed, Approved, or Deprecated
Effective date
Version and change history
Reports, dashboards, scorecards, and other assets using the KPI

Why This Matters

A common issue in enterprise reporting is that multiple teams use the same KPI name but calculate it differently.

For example, an On-Time Delivery KPI might be calculated against the promised date by one team, the requested date by another, while another report may exclude cancelled orders.

All three reports can technically be working correctly, but the organization still ends up with conflicting numbers.

This creates unnecessary reconciliation work and reduces trust in analytics.

Proposed Change Impact Capability

When someone modifies the definition, calculation, threshold, or business rule associated with a governed KPI, Fabric could provide a business impact preview before the change is published.

For example:

Proposed change:
Backlog definition changes from Open Orders > 24 Hours to Open Orders > 48 Hours.

Fabric detects that this KPI is currently used by:

7 Power BI reports
3 scorecards
4 workspaces
2 semantic models

The analyst could then review the affected assets, document the reason for the change, request approval from the KPI owner, and notify downstream report owners before the new definition becomes effective.

A workflow could look like:

Propose Change → Review Impact → Business Owner Approval → Publish → Notify Affected Owners

Business Value

This capability could help organizations:

Create a single trusted definition for critical business metrics
Reduce conflicting KPI calculations across teams
Improve data and reporting governance
Give business stakeholders clear ownership of metrics
Maintain auditability of KPI changes
Understand downstream business impact before changing calculations
Improve trust in Power BI and Fabric reporting
Reduce time analysts spend reconciling why two dashboards show different numbers

Fabric already provides powerful capabilities for data, semantic models, reporting, lineage, and governance. Connecting those capabilities with a governed business KPI lifecycle would help bridge the gap between technical data governance and the way business teams actually define, approve, and use metrics.

IQVIA Lab PM Finance Dashboard

u1106301 — Wed, 26 Aug 2026 13:50:52 GMT

Please update so that line manages and type the names instead of scrolling for each name. Please also allow us to filter more than 1 PM at a time so that we can see our entire team at once.

Show the workspace name for duplicate SQL endpoints with the same name in Desktop PowerBI

WorkFull22 — Wed, 26 Aug 2026 10:52:54 GMT

When multiple Fabric SQL endpoints have the same name, Power BI Desktop should display the source workspace name alongside the endpoint name during connection and in imported table metadata, so users can distinguish between dev, test and prod sources.

Currently the only thing to determine in the report is connected to a dev, test or prod SQL endpoint is to look at the SQL endpoint ID which is still not clear and requires users to wither reconnect or open the workspace in the web and get the SQL endpoint ID that way.

Enable Service Principal (SPN) authentication for SharePoint connector in Dataflow Gen2

v-nandagm — Wed, 26 Aug 2026 09:40:15 GMT

Enable Service Principal (SPN) authentication for SharePoint connector in Dataflow Gen2

Add "Add to Dictionary" and "Ignore All" Functionality to Power BI Text Boxes

mmartelozzo — Wed, 26 Aug 2026 05:14:54 GMT

When creating professional Power BI reports, legitimate company names, project names, industry-specific terms and technical terminology are sometimes incorrectly flagged as spelling errors with a red underline.

The red underline remains visible even when the text box is not being actively edited, which can be distracting during report design and review.

Example:

Pumpouts

Pumpouts has a red underline underneath it.

pumpouts as well

Power BI Desktop does not appear to provide an "Add to Dictionary" or "Ignore All" option similar to Microsoft Word and Outlook.

Suggested enhancement:

Add the ability to:

Add a word to a custom dictionary
Ignore a word once
Ignore a word throughout the report

Benefits:

Improves report presentation and professionalism
Supports legitimate company names and industry terminology
Provides consistency with other Microsoft products such as Word and Outlook
Reduces unnecessary spelling warnings in business reports
Developers dealing with company names, acronyms and industry terminology would have an option to remove the red underline.

Copilot Dynamic Report Subscriptions

Swarly_P — Tue, 25 Aug 2026 23:42:44 GMT

SLT loves the copilot summary in the report subscriptions, however, only the standard subscription includes the summary and there is a 24 subscription cap for standard. Would really love to see copilot extended to the dynamic subscriptions.

Semantic Model 'Make Changes to this Model'

RobRayborn — Tue, 25 Aug 2026 13:40:11 GMT

The link or action item to make changes to the importing Semantic Model is to obscure.
Nobody looks down in bottom right corner of the Power BI Desktop window unless they want to resize the current view. Please find a better way to present this notification.

Matrix Visual Missing Horizontal Scrollbar When Using Multiple Row Fields

MERTARSLAN64 — Tue, 25 Aug 2026 13:29:46 GMT

Hello Power BI Team,

I would like to report what appears to be a limitation or usability issue with the Matrix visual.

I am using a Matrix with a large number of fields placed in the Rows section (approximately 22 fields). As the hierarchy becomes wider, the content extends beyond the visible area of the visual. However, the Matrix does not provide a horizontal scrollbar, making it impossible to navigate and view the deeper hierarchy levels.

I have already tried:

Disabling Auto-size column width
Resizing the visual
Moving fields to Values and Columns for testing
Various formatting options

The horizontal scrollbar still does not appear when the hierarchy is built through Row fields.

From a user perspective, if content exceeds the visible width of the visual, horizontal navigation should be available regardless of whether the width is created by Columns or by deep Row hierarchies.

Could you please confirm whether this is:

An intended limitation of the Matrix visual, or
A known issue that may be addressed in a future update?

Thank you.

Kind regards,

Mert Arslan

UDF not visible in report

ivana_tomekova — Tue, 25 Aug 2026 12:21:18 GMT

It would be great, if Functions created in the model are also shown in reports live connected to the model.

For the moment, calling UDF from model is working, but function is not visible in report. You must know the name from model, used it and it works. Although report behaves like it does not know it and autosuggestions are not working:

UDF from shared model visible in thin report

ivana_tomekova — Tue, 25 Aug 2026 12:19:55 GMT

It would be great, if Functions created in the model are also shown in reports live connected to the model.

Allow Microsoft Entra ID security groups to own Power BI semantic models

IanKuo — Tue, 25 Aug 2026 09:21:50 GMT

Power BI semantic model ownership is currently associated with a single user account.

This creates an operational single point of failure for scheduled refresh, data source credentials, urgent support, employee vacation, OOO, role changes, and offboarding.

Please allow a Microsoft Entra ID security group to be assigned as the management owner of a semantic model.

The management owner and refresh identity could be separated:

1. Management owner:

Microsoft Entra ID security group

2. Refresh identity:

Service account, service principal, managed identity, gateway connection, or other supported credential identity

Authorized group members should be able to manage scheduled refresh, connections, parameters, and credentials without repeatedly taking over the semantic model.

All changes could remain attributable to the individual group member in the audit log.

This would remove individual ownership dependency while preserving authentication, auditing, and least-privilege controls.