Fabric Ideas Ideas

Allow the target pipeline reference in Invoke Pipeline / ExecutePipeline to be set dynamically

JONATHANHAUN — Fri, 18 Sep 2026 18:29:47 GMT

Problem
Today, the Invoke Pipeline activity (and legacy ExecutePipeline) requires picking the target pipeline statically at design time — a fixed Workspace/Pipeline selection in the UI, which serializes as a literal referenceName GUID in the pipeline's JSON. There is no way to set this reference via an expression or parameter.

This breaks down for any generic, queue-driven orchestration framework where a "dispatcher" pipeline needs to invoke whichever pipeline a config table says to run next. Concretely: our framework maintains a metadata-driven pipeline configuration table (pipeline name plus source/destination/routing attributes) and a queue-processing engine that reads the next pipeline name to run and needs to invoke it generically. Every time a new pipeline is added to that config, we currently have to hand-add a matching case to a Switch activity, each containing its own static Invoke Pipeline/ExecutePipeline targeting that one pipeline by GUID. This is pure maintenance drift — the exact bug we hit was a Switch's defaultActivities firing ("A Proper PipelineName was not passed in") simply because new pipelines were added to the config but nobody remembered to add matching cases to the Switch.

What we tried, and why it's a worse trade-off than fixing this natively
We looked up the target pipeline's item GUID at runtime from a metadata table (populated by a helper pipeline that syncs item names to IDs) and tried invoking it via a WebActivity calling the Fabric REST API's job-trigger endpoint (POST /v1/workspaces/{ws}/items/{itemId}/jobs/instances?jobType=Pipeline) with a manual Until-loop poll to emulate waitOnCompletion. This technically works, but:

It requires setting up a separate OAuth2/Service-Principal-authenticated Web connection just to call Fabric's own API from within Fabric — extra infrastructure and credential management for something that should be native.
It's asynchronous by nature, so we lose native failure propagation (.error.message on the calling activity) and have to hand-roll polling and error-message extraction from failureReason.
Most importantly, we're not confident it preserves Spark high-concurrency session sharing (sessionTag) the way a natively-orchestrated Invoke Pipeline/ExecutePipeline call does, since the REST-triggered run has no recorded parent-child relationship in the orchestration engine's own run lineage — it's an entirely independent top-level run from the platform's point of view.

We also confirmed directly that ExecutePipeline's referenceName genuinely cannot be an expression today — attempting one causes Fabric's Git-integration deploy layer to fail with DiscoverDependenciesFailed, since it needs to statically resolve pipeline dependencies at deploy time.

Ask
Allow Invoke Pipeline's pipeline reference (and/or workspace reference, for cross-workspace scenarios) to be set via a dynamic expression — e.g., bound to a parameter, variable, or Lookup activity output — in addition to the existing static picker. This would let a single generic dispatcher activity invoke any pipeline by name/ID resolved at runtime, with all the native benefits (waitOnCompletion, error propagation, and session-pool participation) that a hardcoded reference gets today. If a fully dynamic dependency graph is a deployment/Git-integration concern, even a documented, git-integration-excluded "dynamic mode" (accepting that dependency discovery can't statically validate it) would be a major improvement over the current all-or-nothing static requirement.

Reset Bookmark Navigator Selection to the Default Published View on Browser Refresh

vivek12344 — Fri, 18 Sep 2026 17:48:55 GMT

In Power BI Service, when a user selects a bookmark through a Bookmark Navigator, the bookmark identifier is appended to the report URL. If the user refreshes the browser page, the report reloads in the previously selected bookmarked state instead of returning to the report's default published view. This occurs even when persistent filters are disabled and report consumers are prevented from saving personalized filter states.

Business Requirement: Customers would like an option that allows report authors or administrators to configure bookmark behavior so that browser refresh always returns users to the default published bookmark/view, regardless of the bookmark selected before the refresh.

Current Behavior: User selects a bookmark from a Bookmark Navigator.

Bookmark state is stored in the URL.
Refreshing the browser reloads the same bookmark.
Report does not return to the default published view.

Expected Behavior: Provide a configurable setting that allows one of the following:

Always reset to the default published bookmark when the browser is refreshed.
Ignore bookmark URL parameters on refresh.
Allow report authors to choose whether bookmark state should persist or reset after refresh.

Value of Enhancemen:Adding a configurable bookmark reset option would:

Improve user experience.
Provide consistent behavior with organizations' default-view requirements.
Reduce support incidents related to bookmark persistence.
Give report authors greater control over navigation behavior in Power BI Service.

Separate Interactive and Background Compute Allocation to Prevent Throttling of Live Reports

TilakArani — Fri, 18 Sep 2026 17:21:01 GMT

Problem Statement

When Fabric capacity utilization reaches or exceeds 100% in the last one-hour window, end users experience significant disruptions when accessing Power BI Fabric live reports. This occurs because scheduled jobs, on-demand jobs, and Spark sessions consume compute resources without differentiation from interactive workloads.

Current Impact:

Live reports fail to open or become unresponsive for end users
Interactive user experience is severely degraded due to background job consumption
Business-critical reporting becomes unavailable during peak processing times
No mechanism exists to prioritize user-facing workloads over batch operations

Proposed Solution

Implement a dedicated compute allocation model that separates interactive and background workloads within Fabric capacity:

Key Features:

Reserved Interactive Compute Pool
Allocate a guaranteed percentage of capacity exclusively for interactive workloads (e.g., live reports, ad-hoc queries, user interactions)
This reserved pool should be protected from background job consumption
Ensure interactive compute never gets throttled regardless of background job activity
Background Job Compute Management
Assign scheduled jobs, testing jobs, on-demand pipelines, and Spark sessions to a separate compute pool
Implement automatic job cancellation or queuing when background compute allocation is exhausted
Prevent background jobs from consuming resources beyond their allocated threshold
Intelligent Throttling Logic
When background compute reaches its allocated limit (e.g., 70-80% of total capacity), automatically:
Queue new job requests
Cancel or pause non-critical Spark sessions
Prioritize critical scheduled jobs based on defined priorities
Interactive workloads should remain unaffected and continue to operate within their protected allocation

Configurable Allocation Settings

Allow capacity administrators to define the split between interactive and background compute (e.g., 30% interactive / 70% background)
Provide flexibility to adjust allocations based on organizational needs and usage patterns
Enable time-based allocation policies (e.g., higher interactive allocation during business hours)

Expected Benefits

Improved User Experience: End users can reliably access live reports without interruption
Predictable Performance: Interactive workloads maintain consistent performance regardless of background activity
Better Resource Management: Clear separation enables more effective capacity planning
Reduced Business Impact: Critical reporting remains available even during heavy batch processing
Enhanced Control: Administrators gain granular control over workload prioritization

Business Justification

Organizations invest in Fabric capacity to support both analytical processing and real-time business intelligence. When background jobs monopolize resources, the primary business value—timely access to insights—is compromised. This feature would ensure that interactive reporting, which directly serves business decision-makers, receives guaranteed compute resources while maintaining efficient batch processing capabilities.

Additional Considerations

Provide monitoring dashboards showing real-time allocation and usage across both compute pools
Include alerting when either pool approaches its limits
Allow emergency override capabilities for critical batch jobs when needed
Consider implementing burst capacity options where interactive workloads can temporarily borrow from background allocation if available

Data Lineage support for Notebooks

JulianThomas — Fri, 18 Sep 2026 12:55:44 GMT

I would like to be able to utilise and benefit from the Data Catalog Data Lineage, even when I am not utilising the required Pipeline Activities that generate Data Lineage metadata.

I think this should be easy to do, if we can expose at least parts of the the api via python, so that when we are creating notebooks, we can setup similar metadata to our pipelines, allowing notebooks to be included in the data lineage. Possibly even allow this for SQL type code that could be executed as well.

Display Table[Column] instead of Column Name in Conditional Formatting Dialogs

Manickambeeie — Fri, 18 Sep 2026 12:03:31 GMT

In large-scale Power BI semantic models, it is common to have identical column names across multiple fact and dimension tables. Examples include columns such as Status, Category, Region, Employee ID, Created Date, and Priority.

When configuring Conditional Formatting (Icons, Font Color, Background Color, Data Bars, Field Value, Rules, etc.), Power BI often displays only the column name and does not clearly indicate the source table.

Displaying Table[Column] would improve report governance, debugging, and developer productivity.

Native SAP SuccessFactors and Active Directory Connectivity for Simplified Data Integration

João_Cristo — Fri, 18 Sep 2026 11:25:04 GMT

Having native connectors for SAP SuccessFactors and Active Directory would eliminate the need for workarounds such as notebooks, custom scripts, or complex integration setups. Users should be able to create a standard connection and use Copy Data pipelines directly, just like with other supported data sources. This would simplify data ingestion, reduce implementation effort, improve reliability, and make HR and identity data integration much easier to manage in Microsoft Fabric.

Allow Azure Databricks streaming tables to be mirrored into Fabric

_taab — Fri, 18 Sep 2026 10:13:41 GMT

Mirroring an Azure Databricks Unity Catalog into Fabric silently drops streaming tables. They are not greyed out, not flagged, not explained. They simply do not appear in the picker, so there is no way to select them. We have tested this and the documentation confirms it: materialized views and streaming tables will not be displayed.

The reason this is hard to accept is that the data already qualifies.

Mirroring for Azure Databricks does not copy anything. It creates OneLake shortcuts to the Delta data in place, which is exactly why Microsoft markets it as unified access without data duplication. So the only question that should matter is whether the object is a Delta table in Unity Catalog.

It is. Databricks documentation states that all Unity Catalog managed tables and streaming tables are Delta tables, and that a streaming table is a Unity Catalog managed table with extra support for incremental processing. Microsoft's own Learn documentation for Azure Databricks describes streaming tables as Lakeflow declarative pipeline datasets backed by Delta Lake. Two sets of Microsoft-published docs say these are Delta tables, and the third filters them out of the mirroring picker with no stated technical reason.

This is not a niche object type. Every output of a Lakeflow or DLT pipeline is a streaming table, and declarative pipelines are the pattern Databricks recommends for building curated silver and gold layers. The practical result is that the tables an organisation most wants to serve to Power BI, semantic models and data science workloads are precisely the ones mirroring refuses to show. A huge share of our own curated estate is unreachable from Fabric for this single reason.

The only workaround is to write jobs that copy every streaming table into a plain Delta table so the picker will accept it. Duplicate storage, ongoing compute to keep the copies current, latency added on top of pipelines built for incremental processing, and governed data existing twice with the second copy outside the lineage of the pipeline that produced it. We are paying, in cash and in engineering time, to reintroduce exactly the duplication that mirroring was built to eliminate.

The ask:
Include streaming tables in the mirrored catalog picker and shortcut them like any other Unity Catalog Delta table. If there is a genuine constraint, for example around managed storage paths or pipeline maintenance operations rewriting files, then say so in the documentation and give us opt-in support with that caveat written down. Right now the limitations page lists streaming tables alongside Delta sharing tables and RLS-protected tables with no explanation of why, and teams only discover the gap after they have committed to the architecture.

Fabric is meant to be where the whole estate comes together. For anyone running declarative pipelines on Databricks, this one exclusion decides whether that is true or not.

References:
https://learn.microsoft.com/en-us/fabric/mirroring/azure-databricks-limitations
https://learn.microsoft.com/en-us/fabric/mirroring/azure-databricks
https://learn.microsoft.com/en-us/azure/databricks/tables/delta-table

Power BI, import report and semantic model: show change connection pop-up

Reitse — Fri, 18 Sep 2026 08:57:51 GMT

When you need to import an existing Power BI report and semantic model in Tenant B that's created in Tenant A, you need to jump through a number of hoops to fix the original connection. It's doable, but overly complex.

Why not, on import, show a pop-up that offers to change the connection in the PBIX file to one that is available in the Tenant B (or is created when importing the report). It will save time, and frustration.

Enable per-user security for shared gateway connections using service accounts

AshishChougala — Fri, 18 Sep 2026 08:39:14 GMT

When a shared gateway connection uses a highly privileged service account, all source queries run with that account’s permissions. Users cannot see the stored credentials, but report developers who can use the connection may access any data available to the service account.

Currently, gateway permissions control who can use the connection, but cannot restrict source access by user, Microsoft Entra group, workspace, or semantic model.

Please add granular security controls that allow administrators to:

Restrict source objects by user, group, workspace, or artifact.
Approve which artifacts can use a shared connection.
Separate refresh permission from permission to create new connections or bindings.
Enforce the individual user’s source permissions for Import-mode development and refresh.

This would enable secure self-service reporting with centrally managed credentials, without requiring DirectQuery or multiple gateway connections.

Power BI - incorrect handling of empty string parameter in DAX query in paginated report

roshinikumarkar — Fri, 18 Sep 2026 03:44:45 GMT

Blank string parameters in paginated reports are treated as empty strings in Power BI Report Builder but as null values in the Power BI Service, resulting in incorrect report output.

-> Create a paginated report.
-> Create a string parameter that:

Allows blank
Does not allow null.

Expects both environments to behave the same way. Since the parameter is configured to allow blanks but not nulls, expect the Power BI Service to pass an empty string ("") rather than NULL.

Support Managed Private Endpoint for Azure DocumentDB (with MongoDB compatibility)

morten-gn — Thu, 17 Sep 2026 19:42:37 GMT

Fabric does not offer a secure way to connect to Azure DocumentDB (with MongoDB compatibility).

It is currently only supporting the Azure Cosmos DB for MongoDB

Enable Analyze in Excel / live connection for external (cross-tenant) users

mholtmailctpcom — Thu, 17 Sep 2026 19:26:54 GMT

Enable Analyze in Excel / live connection for external (cross-tenant) users

Support Encrypted Sensitivity-Labeled Excel Files in Power Query

ewarstdhyjugkhi — Thu, 17 Sep 2026 17:19:28 GMT

Description

Currently, Power Query Online and Power Query in Excel are unable to access encrypted Excel files. Excel files with sensitivity types other than Public or Non-Business can be encrypted and therefore cannot be accessed through Power Query Online or Power Query in Excel.

We would like to request support for accessing and processing sensitivity-labeled encrypted Excel files through Power Query while honoring the security and access permissions associated with the sensitivity label.

Business Impact

Organizations increasingly use sensitivity labels and encryption to protect business-critical and confidential information. At the same time, these Excel files may need to be used as data sources for reporting, analytics, and data transformation scenarios.

The current limitation can prevent customers from using protected Excel files directly with Power Query Online or Power Query in Excel, requiring them to reconsider either their data protection approach or their Power Query workflow.

Feature Request

Please consider enabling Power Query Online and Power Query in Excel to:

Authenticate authorized users when accessing sensitivity-labeled encrypted Excel files.
Access encrypted Excel files when the signed-in user has appropriate permissions.
Honor the sensitivity label, encryption, and associated access controls while processing the workbook.
Provide Power Query functionality without requiring customers to remove or downgrade the sensitivity protection applied to the source Excel file.

This enhancement would help organizations maintain their information protection requirements while continuing to use Power Query for their data transformation and analytics needs.

Auto-propagate Lakehouse (Direct Lake) permissions to users assigned to a Power BI App audience

majofv — Thu, 17 Sep 2026 14:44:39 GMT

Problem

When a Power BI report uses a Live Connection to a Direct Lake Semantic Model, end users must have explicit ReadAll / ReadData permissions on the underlying Lakehouse (or its SQL analytics endpoint) — because Direct Lake reads the Delta files from OneLake at query time.

However, assigning users to an App audience that includes such a report does not automatically grant them the required Lakehouse permissions. As a result, users added to the audience open the report and see "You don't have permission to view the content of the Direct Lake table", even though they have been explicitly granted access to the content through the App.

This is especially painful with B2B guest users, and when permissions are managed through Microsoft 365 groups, whose membership does not reliably resolve for OneLake/Direct Lake permission evaluation. Today the only robust workaround is to assign each user individually at the Lakehouse level — which does not scale and defeats the purpose of App-based distribution.

Proposed idea

When a report backed by a Direct Lake Semantic Model is published in an App, and a user (or group) is assigned to an audience that has access to that report, the required Lakehouse permissions (Read / ReadData / ReadAll) should be propagated automatically at navigation time — scoped to the datasets/tables the report actually consumes.

In other words: if content is distributed through the App and a user is granted access to it, it should be implied that the user is allowed to read the data behind it, without the administrator having to separately manage Lakehouse permissions.

Why this matters

The current design creates a contradiction between two Fabric optimizations:

Capacity optimization (Direct Lake avoids importing/refreshing data and reduces capacity resource usage) — a clear improvement.
Content distribution (App audiences are meant to be the simple, governed way to share content) — which is degraded, because App assignment alone is no longer sufficient to actually view the report.

What is solved on one side (resource efficiency) is worsened on the other (distribution and access management). Aligning permission propagation with App audience assignment would remove this friction and make Direct Lake a viable choice for broadly-distributed reports without per-user manual permission management.

Impact

Eliminates the "You don't have permission to view the content of the Direct Lake table" error for users legitimately granted access via App.
Removes the non-scalable per-user manual Lakehouse assignment workaround.
Fixes the broken experience for B2B guest users and Microsoft 365 group-based sharing.
Makes App-based distribution consistent between Import and Direct Lake storage modes.

Add a Close or “Return to previous page” button to Semantic Model Security and Settings pages

Kalaiselvan — Thu, 17 Sep 2026 12:01:34 GMT

When updating RLS group assignments through Semantic model > Security, there is no consistent in-product Close or Done button that returns the user to the previous workspace view.

The browser Back button can sometimes be used, but it may not preserve the workspace search, filters, sorting, or scroll position. This makes repetitive administration difficult when managing several semantic models.

Please add a Close, Done, or Return to previous page button to Semantic Model Security, Settings, Permissions, and similar administration pages. It should return the user to the exact previous workspace context.

Alternatively, open these experiences in a side pane so administrators can make changes without leaving the workspace. Microsoft already provides a preview semantic-model settings pane that keeps the surrounding context visible, and extending this pattern to RLS Security would improve consistency and productivity.

Enable SharePoint File Support in Fabric Copy Jobs

arno_cd92 — Thu, 17 Sep 2026 08:25:46 GMT

Idea description

Microsoft Fabric Copy Jobs currently do not support reading from or writing files directly to SharePoint sites. This limitation makes it difficult to implement straightforward and reusable data integration workflows involving documents and files stored in SharePoint.

We would like to see native SharePoint file support added to Fabric Copy Jobs, enabling users to copy files between SharePoint and Fabric storage destinations, without requiring additional workarounds or custom implementation.

This capability would simplify data ingestion

Add a "Collapse All Code Cells" option in Fabric Notebooks

arno_cd92 — Thu, 17 Sep 2026 08:09:33 GMT

Title: Add a "Collapse All Code Cells" option in Fabric Notebooks

Fabric Notebooks currently allow users to collapse code cells individually. However, in large notebooks, manually collapsing each cell is time-consuming.

Please introduce a "Collapse All Code Cells" command that collapses all code cells in a single action while keeping Markdown cells, especially headings, expanded and visible.

This would improve notebook readability, navigation, and productivity during code reviews, documentation, and presentations. A complementary "Expand All Code Cells" option would also be valuable.

Request to add a feature to extract gateway connection status and last time credentials used

Vinodkumar_Chak — Fri, 18 Sep 2026 07:11:53 GMT

Could you please add a feature in the admin UI on Microsoft Fabric/Power BI to extract the Gateway connections with details of the gateway connection status and last activity information along with the connection name, users, and connection type.

Current Limitation

Administrators can manage gateways through the Power BI Service, but there is currently no simple way to use PowerShell to extract operational details such as:

Gateway connection status (Online/Offline)
Last successful connection timestamp

This capability is important for our internal stakeholders from an audit and governance perspective, as it would help maintain a streamlined and well-governed Power BI environment.

As part of the company's cloud modernization initiative, our internal teams are planning to extract connection information to identify which connections are still required and which can be safely decommissioned. This analysis is necessary to identify on-premises server dependencies and develop a migration plan to the cloud.

Currently, because there is no way to determine which connections are active and which are inactive, it looks like the exercise becomes complex. Having this functionality available would greatly improve visibility, governance, and migration planning efforts. Thanks.

Extend Outbound Access Protection to support Power BI / Org Apps

JamesM999 — Thu, 17 Sep 2026 07:42:37 GMT

Request

I would like to request that Outbound Access Protection support includes Apps in addition to Reports and Semantic models please.

Enabling OAP on reporting workspaces restricts semantic model developers to querying approved data sources. Nice.

We would like to deploy reports built on these models to end users via Apps. Unfortunately, Org Apps are not currently supported in the Preview version of OAP for Power BI.

Background

This is on the back of support ticket: 2609160030000624. The link below specifically says that Org Apps are not supported yet (and the option is greyed out in the 'New Item' window). No mention of Power BI Apps though. The button to create the older Power BI Apps is still available, but I received an error when trying to create the app, so I assume they are unsupported as well?

Fabric security features availability - Microsoft Fabric | Microsoft Learn

Support parameterized file destination paths in Copy job

ryomaru0825 — Thu, 17 Sep 2026 06:36:49 GMT

Currently, the file destination path in a Fabric Copy job is defined statically in the job configuration.

Please add support for parameterizing the destination file path, including folder and file names, so that the output location can be dynamically controlled at runtime.

For example, it should be possible to define an output path such as:

Files/output/{run_date}/{run_id}/

where run_date and run_id are supplied dynamically at runtime.

It should also be possible to pass these values from a pipeline or other orchestration process.

This would enable a single Copy job definition to be reused across different executions without creating multiple Copy jobs that differ only in their destination paths.

Use cases

Create execution-specific output folders using run_date and run_id
Dynamically partition output files by processing date
Prevent outputs from different executions from being mixed or overwritten
Pass destination path values from a pipeline or orchestration process
Reuse the same Copy job definition across multiple executions and environments