Having the ability to run python code outside of the notebook environment (like we can for pyspark jobs) could be a real win for efficiency and modularity. It would allow users to package robust, unit-tested code and deploy it to the fabric environment where it could run as a cost-effective single-node job. Databricks has an implementation for this, and it would be really nice to see something similar come to Fabric. Notebooks are great for ad-hoc or exploratory stuff, but building something robust in them feels like shoving a peg into a wrong-shaped hole. They are (nearly) impossible to unit test, so you often end up creating libraries which allow you to package transformations in a way that can be tested, then your notebooks end up being essentially thin wrappers around a bunch of external code. I think the most obvious example for this is the number of Fabric DBT implementations that essentially involve installing DBT core into a notebook and running it there (I know there is DBT jobs coming, but this is beside the point). This is a symptom of a larger need for this type of hosting/execution of code within the environment. Yes, you could host the code on a vm external to Fabric but that goes against the ethos of a unified data platform. Offering something like this would be a great way to increase the flexibility and extensibility of the platform. The implementation can be fairly barebones and developer forward, aiming to provide maximum flexibility and extensibility. Basically a way to run python scripts/CLI tools on the Fabric capacity.    ... View more

At present, the Power BI Admin Activity Events API supports retrieving audit events only for a maximum lookback period of 28 days. This limitation poses challenges for organizations that require long-term retention, historical analysis, compliance reporting, or forensic investigations based on audit data. We would like to request an enhancement to this functionality, enabling the retrieval of activity events beyond the current 28-day restriction. Having the ability to access historical events without time-based limitations would significantly improve administrative visibility, governance, and compliance capabilities for enterprise customers. ... View more

 Yes please to custom access messaging - upvote the socks off this post! We stilll have a gap in the access messages feature in Power BI in 2026 - lets see if we can muster enough upvotes to change it! Semantic models can have a unique access message on them, however workbooks cannot have a unique access message on them. If you host hundreds of Power BI reports, the administration on the dreaded default "I would like access" message is no fun. Users today have their own sharepoints, documents, why cant we have the functionality on customization of that dreaded access message?     Yes you can use the app to change it in a workspace, but the issue with that is only one app per workspace is allowed. Why should users opt to add more workspaces making topologies more complex when they need not have to be that way. Org apps is introduced 2026 which allows multiple apps per workspace - but only one access message is allowed. This should be a standard in apps if were moving that way, each app should be capable of having a customized message per app. We get user complaints all the time on this subject, from the many posts even this one as solved so do others.   Two things i would like this idea to change which would give a gain to anyone who administers a workspace. 1. Workbook access message customization for those who dont want to use the app as standard in 2026. 2. Org apps to include custom message per app as standard in 2026.   What do we need to facilitate change? Upvotes, encourage all your users to upvote this proposal and add some comments, lets see in 2026 if we can fix this issue!  ... View more

Problem statement: Fabric Data Factory copy activity error messages when sink is lakehouse are very generic. Example: Failure happened on 'Sink' side. 'Type=Microsoft.Data.DeltaLake.MetadataChangedException,Message=conflicting metadata change,Source=Microsoft.DataTransfer.ClientLibrary,'   If we could gain better visibility on what is the column causing the issue or stack trace to expose a bit more technicalities it would be easier to investigate FDF errors - potentially we wouldn't also need to engage Fabric support team for root cause analysis. We would like to see error messages which are detailed to the same extent as in Azure Data Factory. ... View more

Description: Currently, export format settings for paginated reports can only be controlled at the tenant level or security group level via admin portal settings. There is no way to restrict export formats (e.g., allow only PDF) on a per-report or per-workspace basis.   Business Scenario: For compliance and audit purposes, some reports must be exported only in specific formats (e.g., PDF only). With the current design, disabling Excel export applies to all paginated reports in the tenant, which is too broad and impacts other use cases.   Requested Feature: Please add the ability to configure allowed export formats at the report level or at minimum at the workspace level, so that specific reports can be locked to PDF-only export for audit/compliance purposes. ... View more

Description Hi community, I’d like to raise a feature request related to governance and connection management in Microsoft Fabric, specifically for Email (Office 365 Outlook) and Microsoft Teams connectors used in Data Factory pipelines. Scenario In enterprise environments, it is common to require: Centralized management of connections (e.g., Email / Teams) Reuse of the same connection across multiple workspaces (Dev/Test/Prod, or multiple domains) Consistent governance, including credential lifecycle management and auditing However, when working with Fabric pipelines that use Outlook or Teams activities, we observed the following behavior: When deploying a pipeline to another workspace, the activity becomes inactive A new user authentication connection must be created in the target workspace If the connection is not recreated, deployment fails or the activity cannot run This behavior is documented here: Outlook activity → Microsoft Learn Teams activity → Microsoft Learn Current Behavior (Documented Limitation) As per official documentation: Outlook / Teams connections are tied to user authentication When moving pipelines across workspaces: “The activity will be inactive in the target workspace until you create a new user authentication connection there” [learn.microsoft.com] Same behavior applies to Teams activity [learn.microsoft.com] This effectively means: Connections are scoped to the workspace Connections are not reusable across workspaces Each workspace requires manual reconfiguration Expected Behavior From an enterprise governance perspective, we would expect: Ability to define centralized, reusable connections Secure sharing of those connections across multiple workspaces Support for CI/CD scenarios without manual re-authentication Reduced duplication of connections and credentials Why this matters Other connection types in Fabric (e.g., cloud connections) are moving toward shared and governed models, but Email and Teams connectors still require per-workspace authentication. This creates an inconsistency in the platform’s governance model, especially for enterprise adoption. Feature Request We would like to request support for: Secure, reusable Email and Teams connections Cross-workspace connection sharing Centralized management (similar to cloud connections / gateways) CI/CD-friendly connection lifecycle ... View more

Currently, sending email subscriptions to external recipients is supported only when the workspace is backed by a paid Premium capacity, and not in trial or non‑Premium environments [Email subs...soft Learn | Learn.Microsoft.com] This limits customers from validating external reporting and collaboration scenarios during trials.   Allow external email subscriptions in: Trial environments Non‑Premium (Pro/PPU) workspaces (with controlled limits) Impact Enables proper feature evaluation during trial Improves adoption for external collaboration scenarios ... View more

The current card visual forces users to overlap elements or waste copious amounts of time creating custom visuals. The new card feature should give users the ability to create multiple cards in a single container and provide a greater level of customization. ... View more

It would be beneficial to incorporate features from Pivot tables that allow for the expansion and collapse of columns and hierarchical column groups within tabular visuals. This would not only solve the current limitations of matrices but also provide report creators with the flexibility to hide and show rows and columns, saving these settings for future use, thus eliminating the need to scroll through irrelevant data. ... View more

This feels like a genuine design bug related to how Fabric and Power BI fit together. I'm working in a workspace backed by an F64 Fabric capacity. Using the same user account (Fabric Free), I can edit and refresh semantic models just fine through notebooks, pipelines, the Fabric CLI, and Git integration (PBIP/TMDL). All of those are documented Fabric paths, and they work as expected. If I try to do the same thing from the Power BI Service UI (for example, manually refreshing the semantic model) I get hit with an "Upgrade to a paid Power BI license" message. Same model, same workspace, same capacity, same user, different outcome. The only difference is whether I clicked a button in the UI or initiated the action through a Fabric surface. The issue is about inconsistent enforcement of the same capability. Whether an operation is allowed shouldn't depend on whether it's triggered via the UI versus Fabric orchestration. That makes behavior feel non‑deterministic and forces operators to avoid the UI entirely for tasks that are otherwise allowed and already running on paid capacity. It also creates artificial licensing pressure. The capacity is paid for, the operation is supported and allowed via multiple paths, but you still need Pro just to press the UI button. That's hard to justify, and it actively worsens governance and operability. There are already community threads where people hit parts of this problem (for example, being blocked from UI refresh with Fabric Free licenses on capacity), but none really address the bigger issue: Fabric allows the operation everywhere except the Power BI UI. At minimum, this should be reconciled. Either the UI entitlement checks should align with what Fabric already allows, or there should be a clear, capacity‑scoped "operator" capability for management of Power BI items. Even clear in‑product guidance explaining why automation is allowed but UI actions are blocked would be better than the current experience. Right now it just feels fragmented. Fabric presents itself as a unified, capacity‑first platform, but the Power BI UI still behaves as if it's living under a separate, legacy licensing model. ... View more

Enabling customized calculations at the query level for subtotals and grand totals would offer greater flexibility in reporting and preserve performance. Efficient organization of control settings to modify the style of these totals separately will empower report creators to achieve their desired appearance, while addressing their need for more control and customization in reporting. ... View more

Imagine a world where report creators can automatically apply slicer and filter selections based on specific logic, revolutionizing data analysis and user experience. This innovative approach eliminates any need for complex workarounds, optimizes slicer functionality, and paves the way for more efficient and effective data reporting. ... View more

Currently when a user create a managed private endpoint from a Fabric workspace to another azure resource, only the workspace name is included in the name. As Fabric can send MPE requests to any tenant, it would be ideal to include the Fabric Tenant Information as well along with workspace ID. This would help the target resource to make sure the request came in from one of their tenants during the MPE approval process. ... View more

Power BI treats text values in the semantic model (VertiPaq / DAX engine) as case‑insensitive. While Power Query (M) is case‑sensitive, once data is loaded into the model: ... View more

Variable Library string values can contain invisible/non‑printable characters. When used in pipelines (e.g. Workspace or Dataflow references), this can cause opaque runtime failures surfaced as generic 500 “token access” errors. Suggestion: warn or block non‑printable characters (especially leading/trailing), or surface a clear validation error instead of InternalServerError. ... View more

Dataverse Virtual Tables currently do not support File, Attachment, or Image data types. When binary content (for example images, videos, ZIP files, or documents) is exposed from external sources such as Microsoft Fabric Lakehouse, Azure Blob Storage, or SQL, Dataverse treats the data as text and applies strict character-size limits. This results in truncated Base64 content and prevents proper rendering or access to the original files.   Solution: Allow virtual tables to reference externally stored binary data via streaming Enable secure rendering or download via Dataverse  This enhancement would allow customers to: Keep binary data in Fabric or Blob Storage Render images and access files directly in Dataverse apps Avoid duplication, reduce storage costs, and simplify architecture ... View more

Interpreting visuals without a clear legend to indicate logic behind specific styles can lead to confusion and decision-making errors. An idea to enhance clarity and transparency by ensuring legends and tooltips accurately display colors, patterns, and other visual components influenced by logics, would enable report consumers to easily understand the applied logic and make more effective decisions. ... View more

When using Dataflow Gen2 in Microsoft Fabric, parameters behave differently depending on how the Dataflow is executed, even when the same parameters and values are used. After detailed investigation and confirmation with Microsoft Support, we observed the following inconsistent behavior: Direct Dataflow execution (via Dataflow UI): When a query or query-related logic is passed as a Dataflow parameter, the Dataflow correctly re-evaluates the query and adapts the schema accordingly. Pipeline-triggered Dataflow execution: When the same parameter is passed from a Pipeline to the Dataflow, the schema is not re-evaluated or adapted, even though the parameter values are identical. Internally, the Pipeline appears to execute the Dataflow using a different execution path / mashup handling mechanism than a direct Dataflow run. This leads to schema mismatches, mashup document errors, or an inability to support dynamic query logic when triggered via a Pipeline.   Why This Is a Problem From a user perspective, Dataflow parameters should behave consistently, regardless of whether the Dataflow is executed directly or via a Pipeline. Currently, solutions that work perfectly in a direct Dataflow run break when orchestrated via Pipelines, even though Pipelines are the recommended orchestration mechanism in Fabric. This limits the ability to build generic, parameter-driven Dataflows that are orchestrated by Pipelines. It also creates confusion, as there is no clear documentation explaining that schema changes are only supported in direct Dataflow runs but not in Pipeline-triggered runs. Expected Behavior Parameter handling and schema evaluation should be harmonized between: Direct Dataflow Gen2 runs Pipeline-triggered Dataflow Gen2 runs If a Dataflow supports schema adaptation based on parameters, this behavior should be identical regardless of the execution method. Alternatively, if there are technical limitations, these should be explicitly documented, including guidance on supported design patterns. ... View more

Idea   Please add a selective sync feature to OneLake File Explorer so users can choose exactly which Fabric items are synchronised to their local machine.   Today, OneLake File Explorer surfaces and reacts to many workspace items that do not make sense in a desktop file sync experience, such as Pipelines, notebooks, Lakehouse table internals, Delta log folders, and other system-generated artefacts. For most users, the practical need is to work with actual files, not every technical item exposed in a Fabric workspace.   What I’m asking for Let users choose which workspace items are synced locally. For Lakehouses, provide an option to sync only the Files folder. Exclude technical and system-managed paths by default, or make them opt-in only. Give admins and users a simple UI to manage sync scope per workspace or per item.   Why this matters Reduces unnecessary CPU, memory, disk, and network usage on client machines. Prevents OneLake File Explorer from processing technical artefacts that are not useful in Windows File Explorer. Makes the product easier to understand for business users and data teams who only want file access. Improves performance and reliability, especially in workspaces with active Lakehouses, Pipelines, and other Fabric items. Aligns the File Explorer experience with real user intent: browse and work with files, not internal Fabric metadata. Preferred behaviour for Lakehouses   When a user connects a Lakehouse in OneLake File Explorer, the default sync option should be: Files only   Advanced users could optionally enable additional paths, but technical folders such as table storage and Delta metadata should not be included by default in the normal desktop sync experience.   Example use case   A user wants to upload and manage CSV, Excel, JSON, and Parquet files in a Lakehouse through Windows File Explorer. They do not want to see or synchronise Pipelines, notebooks, _delta_log, checkpoint files, table metadata, or other internal Fabric-generated content.   This feature would make OneLake File Explorer much more practical, efficient, and user-friendly for real-world Fabric deployments. ... View more