Display Delta table and column descriptions in Fabric Lakehouse Explorer/ Fabric on Browser
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.Consistent Locale Handling Across Power BI, Fabric, PowerPoint, and Subscriptions
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.Make workspace and item session persistence optional
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.
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
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.
Cron based schedules
So here is another MS Fabric frustration that I'd like to share with the community: In schedules for notebooks or pipelines I really miss the possibility to actually use a CRON schedule. This is something I miss and not necessarily the origin of my frustration. My frustration is that today I was experimenting with the Fabric CLI and when through a moment of relief: I noticed that it is possible to set a CRON type schedule (https://microsoft.github.io/fabric-cli/examples/job_examples/#create-cron-based-schedule) However, this frustration was short lived since the functionality of this Microsoft CRON type schedule is not the same as the CRON type schedules I am used to (https://crontab.guru/) I would like to create a schedule that runs on weekdays between 6AM and 7PM, every 15 minutes. This would result in a crontab like this: */15 6-19 * * 1-5. I still did not find a way to create this type of schedule in MS Fabric due to the constraints on scheduling. If I am wrong, please enlighten me. If I am not wrong, here is a kind request for the MS employees to just implement this type of crontab syntax. Kind regards, A tensed MS Fabric Developer.
Workspace Sharing
In the past Power BI Admins had the ability to share a workspace as a whole with an external user to then initiate the invite email. After accessing their external account on our tenant, they could then access any residing report based on RLS security set on the external account. This functionality is no longer available for new Power BI workspaces, and can only be done on individual reports within the workspace. This is time consuming when RLS security is in place and protects against unwanted data access based on the report the external user is viewing. The ability to invite external users to newly created workspaces should be brought back to then help minimize the time spent having to invite external users to individual reports when RLS security is set and manages data viewing access.
USERELATIONSHIP Bug
I have found a bug with USERELATIONSHIP I am not sure exactly WHY it fails in this scenario but it DOES. I raised the below on the forum so more detail can be found here. Essentially I am using Fabric, the keys I am using are 64 bit integers, data type whole number. Running equivalent operations in SQL work just fine, but when using USERELATIONSHIP it fails, which is frustrating as TREATAS does work. USERELATIONSHIP Issue | Microsoft Fabric Community
Enhance Power BI/Fabric Audit Logs with Detailed Action Tracking and Change History
Power BI and Microsoft Fabric audit logs are essential for governance, compliance, security monitoring, and operational auditing. However, several important activities are currently logged with very limited detail, making it difficult to accurately assess user actions and configuration changes. 1. Copilot Audit Logs Today, interactions with Power BI Copilot are typically recorded under the generic RequestCopilot event. As a result, administrators cannot distinguish users who simply submitted prompts from those who performed actions on the generated results. For example, it is currently not possible to identify: Users who only viewed Copilot responses. Users who executed Copy Table. Users who copied generated content. Users who exported or downloaded results generated by Copilot. From a governance, compliance, and data protection perspective, these actions have very different risk profiles and should be tracked separately. Requested enhancement: Introduce dedicated audit events and/or action details for activities such as: CopyTable CopyResponse ExportResults DownloadGeneratedContent Other user actions performed against Copilot-generated outputs 2. Update App Audit Logs The current UpdateApp audit event also lacks sufficient detail for auditing purposes. When an app is updated, administrators cannot easily determine: Which reports were added or removed. Which audiences were modified. Which users or groups were impacted. Which permissions changed. What specific configuration changes were applied. This makes troubleshooting, change management, audit investigations, and compliance reviews significantly more difficult. Requested enhancement: Provide a detailed change log (delta) within the UpdateApp event, including: Added content Removed content Audience changes Permission changes User/group assignments added or removed Before/after configuration details Business Value More detailed audit logs would significantly improve: Security monitoring Data governance Regulatory compliance Internal and external audits Incident investigations Change management Risk management As organizations continue adopting Copilot and Fabric at enterprise scale, audit logs must evolve from activity indicators into true operational and security records that provide full traceability of user actions and configuration changes.Ability to Recover Previous Versions of Power BI Service Reports After Overwrite
Description: Currently, when a report developed directly in the Power BI Service is overwritten, there is no supported method to recover the previous version of the report. In the observed scenario: The report was created and maintained in the Power BI Service. The report was subsequently overwritten by a newer version. An earlier version remained visible in the published app; however, it could not be exported because the "Allow users to make a copy of the reports in app" setting was not enabled when the app was published. Enabling this setting after the overwrite does not restore access to the previous version, as it requires republishing the current report and does not provide a mechanism to retrieve historical versions. Expectation: Providing report version recovery would improve resiliency, reduce the risk of accidental data loss, and help customers quickly restore reports when unintended overwrites occur.
