Enhance Fabric Pipeline Monitoring with Parent-Child Pipeline Lineage and Parameter Visibility
Currently, Microsoft Fabric Pipeline monitoring lacks several capabilities that are available in Azure Data Factory, making troubleshooting and operational support challenging in enterprise environments. Problem: When multiple parent pipelines invoke the same child pipeline through an Execute Pipeline activity, it is difficult or impossible to determine: Which parent pipeline triggered the child pipeline run Parent Pipeline Name Parent Run ID Trigger source information Input parameter values passed to the child pipeline End-to-end execution lineage across parent and child pipelines In many cases, the Upstream Run column remains blank, and monitoring views do not expose sufficient execution details to identify the originating pipeline. Expected Capability: For every child pipeline execution, provide monitoring details such as: Parent Pipeline Name Parent Run ID Child Run ID Execute Pipeline Activity Name Trigger Type (Manual, Schedule, Event, API) Input Parameter Values Pipeline Execution Hierarchy Clickable navigation between parent and child runs Business Impact: Faster troubleshooting and root cause analysis Improved operational monitoring Better auditability and governance Easier migration from Azure Data Factory to Microsoft Fabric Reduced effort for support and production teams This enhancement would bring Fabric Pipeline monitoring closer to the mature monitoring experience available in Azure Data Factory and would be highly valuable for enterprise-scale implementations.
Workspace Folder & Subfolder Inventory View for Power BI Reports and Apps
Problem: Many organisations use Power BI workspace folders and nested subfolders to organise reports by department, business area, project, or function. While this structure helps keep content organised, it becomes difficult to quickly identify: How many reports exist within a workspace Which folders and subfolders contain reports Where a specific report is located Which reports are included in a published App Which reports are no longer used or duplicated Currently, users must manually navigate through each folder and subfolder to locate reports. In large workspaces containing dozens or hundreds of reports, this process is time-consuming and inefficient. Proposed Solution: Introduce a Workspace Content Explorer or Folder Inventory View that provides a consolidated view of all workspace content, including: Folder hierarchy and subfolder structure Report count per folder Complete list of reports with folder paths Search and filter capabilities App publication status Ability to export the inventory to Excel/CSV Option to view reports in a tree structure or flat listAllow 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
