Allow External OneLake Data Shares to Be Accepted into Multiple Fabric Item Types
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.Add an "Explain Effective Access" Experience for OneLake Security
As OneLake Security expands across tables, folders, rows, columns and shortcuts, determining why a specific user can or cannot access data can become difficult. I would like Microsoft Fabric to provide an "Explain Effective Access" experience for OneLake. An administrator should be able to select a user, service principal or group and a OneLake path and see: - workspace and item permissions - applicable OneLake security roles - RLS and CLS policies - shortcut-path permissions - target-path permissions - whether passthrough or delegated authentication is being used - which identity each query engine uses - the resulting effective access - the specific rule responsible for allowing or blocking access The same information should be available through an API for security automation and audit tooling. This would significantly simplify troubleshooting, security reviews and least-privilege validation in enterprise Fabric environments.Tenant-Wide OneLake Shortcut Lineage and Impact Analysis
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.
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.
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.Enable Ownership Change / Take‑Over for Mirrored Database Items in Fabric
Mirrored DBs do not support ownership transfer today. This becomes an issue when someone leaves the company. And the user tied to the ownership is beeing disabled. That means you need to recreate the whole mirroring database and recreate all shortcuts, jobs pipelines etc etc.. Alot of work. The Take‑Over functionality exists for other Fabric items but excludes mirrored DBs. This is a critical operational need for enterprise workloads. Please consider developing this functionality.
API to check that Failure Notifications for Scheduled Pipeline Runs are correctly set up
Please create a GET API endpoint so that we can check whether users have been added to the Failure Notifications list for a scheduled pipeline. Instead of having to check this manually for each pipeline. https://learn.microsoft.com/en-us/fabric/data-factory/create-alerts-for-pipeline-runs#configure-failure-notifications-for-scheduled-pipeline-run
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.
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.
