Background OneLake shortcuts are a powerful feature that enables cross-workspace and cross-domain data virtualization without data movement. However, in real-world enterprise scenarios, especially when using: DirectLake semantic models SQL endpoint / TDS access Cross-workspace shortcut patterns we frequently encounter situations where delegated identity mode is required, and user identity passthrough is not consistently applied. Problem This creates a critical governance and security issue. Access is effectively executed using: connection owner workspace-level identity This means that execution context is delegated away from the calling user. As a result: loss of least-privilege enforcement inconsistent authorization behavior across engines reduced auditability of the actual user accessing the data In practice, this forces architectures where: access must be granted more broadly than intended workspace boundaries do not function as security boundaries users gain indirect access via execution context rather than explicit authorization This contradicts the expected behavior of OneLake security, where access should be governed by both shortcut path and target path permissions. Expected Behavior We would like to see support for the following model: Authentication Workspace Identity (service principal) is used for authentication Authorization The calling user's identity is always used for authorization (User identity passthrough) This should be enforced consistently across: DirectLake SQL/TDS endpoints semantic models all engines accessing shortcuts   Why this matters This hybrid model would: Preserve centralized authentication (Workspace Identity) Ensure true least-privilege access control at the user level Maintain consistent and predictable authorization behavior Eliminate reliance on: delegated identity connection owner context Align shortcut behavior with enterprise governance requirements Current Gap Currently: user identity passthrough is not consistently applied across engines delegated identity introduces execution context delegation Workspace Identity abstracts access but does not preserve user context for authorization Proposed Feature Introduce a new data access mode: Workspace Identity (Authentication) + User Identity (Authorization) Conceptually similar to: On-behalf-of (OBO) pattern in Microsoft Entra ID Additional Considerations Workspace Identity is not merely an abstraction of permissions, but introduces delegation of execution context to the workspace itself. Supporting user identity propagation across engines may require architectural changes. However: The current model, where delegated identity is effectively required in some scenarios, results in less controlled and less transparent authorization behavior. Summary To support enterprise-grade governance and security in Fabric: user identity-based authorization must be preserved end-to-end Workspace Identity should complement user context, not replace it delegated identity should be optional, not required ... View more

  Currently, colors are automatically assigned randomly.  It would be nice if your dev workspace was always blue, and your prod was always pink for example.  Then you'd have a good visual as to where you're working in. ... View more

Today, Workspace Monitoring is configured separately per workspace, which introduces maintenance overhead and likely also a repeated baseline CU cost for each workspace.   Please make it possible to create Workspace Monitoring instances that cover multiple workspaces.   Users should be able to decide how many monitoring instances to configure and which workspaces each instance covers.   This would allow the baseline monitoring cost to be shared rather than incurred separately per workspace, reducing overall cost while also simplifying configuration and ongoing maintenance. In addition, it would enable a more centralized and flexible monitoring setup across workspaces. ... View more

Make it possible to add a description to folders in workspaces.   This would be useful for humans and AI in knowing which content goes into which folder.   Suggested change: In addition to folder name (already possible), make it possible to add a folder description.   The description should be visible when opening the folder, or there could be a small icon we can hover over to see the folder description.   The description should also be a part of Git so that AI can use this information when developing the project. ... View more

In Microsoft Fabric / Power BI, when multiple reports are connected to the same semantic model, Git integration does not preserve or allow control over the default report associated with that semantic model after syncing to a new workspace. This results in unexpected behavior when downloading, modifying, and republishing semantic models—especially after pulling artifacts into a new workspace using Git integration.   Scenario / Reproduction Steps A report is created in Power BI Desktop and published to the Power BI Service. This creates Report 02 test and Semantic Model 02 test. Later, another report is created directly in the Power BI Service using the same semantic model. This creates Report 01 test, also linked to the same semantic model. Both Report 01 test and Report 02 test are linked to the same semantic model in the original workspace, and everything works as expected. Git integration is enabled for the workspace, and all artifacts are pushed to a Git repository. The same artifacts are then pulled into a new workspace using Git integration. Observed Behavior (Issue) In the new workspace, the semantic model automatically selects Report 01 test as the default report. The selection appears to be based on alphabetical order, not on the original or intended default report. When the semantic model is downloaded as a PBIX, modified, and republished: The changes are reflected in Report 01 test instead of the 02 test Report. This issue does not occur in the original workspace and happens only after Git pull into a new workspace. Impact Creates confusion for Fabric admins and developers managing multiple reports per semantic model. Causes unexpected report updates, leading to potential data integrity and governance concerns. Makes Git‑based CI/CD workflows unreliable when: Multiple reports share a single semantic model Default report selection matters for downstream operations. Git integration should provide a way to explicitly define or preserve the default report associated with a semantic model, instead of automatically selecting one based on alphabetical order.   Feature Request Add an option in Git integration / Fabric workspace settings to: Explicitly select or configure the default report for a semantic model or Preserve the original default report association when syncing across workspaces. ... View more

In enterprise environments using Dev / Prod workspaces the current 1,000 item limit per workspace becomes restrictive.   A single domain workspace for ETL activities can easily contain: Lakehouse, Pipelines, Notebooks, Dataflows   Over time, the 1,000 item limit per workspace becomes restrictive and forces teams to: Split domains across multiple ETL workspaces Introduce unnecessary workspace fragmentation Increase permission and governance complexity Add operational overhead The limit works well for small-to-medium environments, but it becomes a constraint at enterprise scale.   Suggestion: Increase the limit or Make it configurable based on capacity (F64/F128) or tenant settings This would reduce workspace fragmentation and better support enterprise-scale Fabric adoption. ... View more

Hello ✌️,   I would like to suggest a new workspace item. A simple wiki. Although it could be integrated within a notebook, this could be overwhelming for people who mostly build reports or similar. Another key benefit of a separate wiki item could be the ability to display it on the workspace landing page. This would replace the 'Import... View' option. To me, as a developer, this looks like a space that needed to be filled somehow, a wiki page would make more sense. ... View more

Hi, during the design of a task flow in a workspace it may happen that a task is accidentally deleted, but it doesn't it exist a manner to restore it: for a such case an undo feature would be very useful to restore the deleted task. Thanks ... View more

Enable the Variable Library as a centralized location for storing all environment‑specific variables, allowing us to adjust them for promotion scenarios (e.g., from dev to prod) without relying on deployment pipelines.   It would be ideal if semantic model parameters or data sources could reference a Variable Library, similar to how deployment pipelines handle variables today. When using CI/CD Option 1 — Git‑based deployments — it isn’t possible to hardcode environment‑specific values or data sources, since these differ across environments. Example: If I build a report in a dev workspace/branch that uses a dev data source, and then promote it to a prod workspace/branch via PR, I have no way to automatically switch the data source to the production version. I would need to submit an additional PR just to update the prod branch, resulting in the same report with different hardcoded sources.  ... View more

Hello team, I would like to propose an improvement regarding item management within Microsoft Fabric workspaces. Currently, it is possible to select multiple items and move them into a folder, which is very helpful for organizing content. However, this same multi-selection capability is not available for deleting items, meaning users must delete them one by one. Proposal Enable bulk deletion of items using the same multi-selection mechanism that is already available for moving items. Motivation In real-world scenarios, especially during development and iterative workflows: Users often create multiple versions of assets (e.g., notebooks, pipelines, etc.) while refining solutions. Once a final or optimized version is achieved, previous iterations need to be cleaned up. Performing this cleanup item by item is inefficient and time-consuming. While it is technically possible to automate this via code or APIs, having this functionality directly in the UI would significantly improve usability and productivity. Risk considerations I understand that bulk deletion can introduce risks. To mitigate them, an approach similar to Azure could be followed: Confirmation prompts (e.g., typing the item name or workspace name). Soft delete or recovery mechanisms, where applicable. Role-based restrictions (e.g., allowing bulk delete only for specific roles such as Admin or Contributor). Suggested approach Extend the existing multi-selection UI to support a “Delete” action. Apply appropriate safeguards (confirmation steps, role validation). Optionally, provide visibility of affected items before confirmation. Expected benefits Faster cleanup of development artifacts Improved user experience and productivity Consistency with existing multi-selection capabilities Reduced friction in iterative development workflows Closing This enhancement would align perfectly with how users already interact with items in Fabric and would remove a small but meaningful point of friction in daily usage. I would be happy to share more detailed scenarios if helpful. Thank you for your continued innovation.   ---------------   Hola, equipo, Me gustaría proponer una mejora en lo que respecta a la gestión de elementos dentro de los espacios de trabajo de Microsoft Fabric. Actualmente, es posible seleccionar varios elementos y moverlos a una carpeta, lo cual resulta muy útil para organizar el contenido. Sin embargo, esta misma función de selección múltiple no está disponible para eliminar elementos, por lo que los usuarios deben eliminarlos uno por uno. Propuesta Permitir la eliminación masiva de elementos utilizando el mismo mecanismo de selección múltiple que ya está disponible para mover elementos. Motivación En situaciones reales, especialmente durante el desarrollo y los flujos de trabajo iterativos: Los usuarios suelen crear varias versiones de los activos (por ejemplo, cuadernos, flujos de trabajo, etc.) mientras perfeccionan las soluciones. Una vez que se alcanza una versión final u optimizada, es necesario limpiar las iteraciones anteriores. Realizar esta limpieza elemento por elemento resulta ineficiente y consume mucho tiempo. Si bien técnicamente es posible automatizar esto mediante código o API, disponer de esta funcionalidad directamente en la interfaz de usuario mejoraría significativamente la usabilidad y la productividad. Consideración de riesgos Entiendo que la eliminación masiva puede conllevar riesgos. Para mitigarlos, se podría seguir un enfoque similar al de Azure: Mensajes de confirmación (por ejemplo, escribir el nombre del elemento o el nombre del espacio de trabajo). Mecanismos de eliminación lógica o de recuperación, cuando corresponda. Restricciones basadas en roles (por ejemplo, permitir la eliminación masiva solo para roles específicos como Administrador o Colaborador). Enfoque sugerido Ampliar la interfaz de usuario de selección múltiple actual para que admita una acción de "Eliminar". Aplicar las medidas de seguridad adecuadas (pasos de confirmación, validación de roles). Opcionalmente, proporcione visibilidad de los elementos afectados antes de la confirmación. Beneficios esperados Limpieza más rápida de los artefactos de desarrollo Mejora de la experiencia del usuario y de la productividad. Coherencia con las capacidades de selección múltiple existentes Menor fricción en los flujos de trabajo de desarrollo iterativo. Cierre Esta mejora encajaría perfectamente con la forma en que los usuarios ya interactúan con los elementos en Fabric y eliminaría un pequeño pero significativo punto de fricción en el uso diario. Con gusto compartiré escenarios más detallados si resulta útil. Gracias por su continua innovación. ... View more

Scheduling Hub   It would be great to to be able to see which items in your fabric workspace (and capacity) have schedules and if they are on or off. A bonus feature would allow you to enable and disable the schedules right from the list view (editing could still open the item in the editor and open the scheduling pane).   Being able to manage schedules from a central location is helpful in 'emergency' scenarios where you need to turn off all the pipelines and notebooks for a workspace. It could also be useful to ensure developers are not mismanaging schedules in Dev or Feature Branch workspaces (where we might typically not want them running). A whole set of useful columns are possible: Item Name  <click on the name to go to the item!> Item Type Workspace Schedule Type Next Scheduled Run Last Scheduled Run   Icons.. Edit Pencil, Enable/Disable, Trash Can The possibilities are endless!   ... 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

To make it easy to filter workspaces, and also enable cost chargeback scenarios, it should be possible to apply Tags to workspaces. ... 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

Currently the .gitignore file is, well, ignored. Ideally we would have a way of using gitignore to avoid committing local developer objects e.g. sandbox lakehouses that developers use for testing out different load patterns. ... View more

I have different workspaces which represent non-prod and then prod. My deployment pipeline will move changes from non-prod to prod. Now when it comes to data factory pipelines with schedules, I want to define the Schedule so it's in source control but I don't want it running in non prod. Let me run that adhoc. But when I push my changes to production via deployment pipeline, let me define a rule to override the Schedule and enable it.  ... View more

  The current inability to parameterize connections in pipeline activities means we need to use the same identity to run the pipeline activities across dev/test/prod environments.   This means the same identity needs to have write access to all environments dev/test/prod.   This creates a risk that code executed in dev writes data to prod, because the identity has write access to all environments.   Please make it possible to parameterize the connection of all pipeline activity types, so we can isolate the identities for dev/test/prod and make it physically impossible for a dev pipeline activity to write data to prod environment.   Here's an overview based on my trials and errors:   Activities that do have "Use dynamic content" option in connection:   - Copy activity  - Stored procedure  - Lookup - Get metadata - Script - Delete data  - KQL   Activities that do not have "Use dynamic content" option in connection:   - Semantic model refresh activity  - Copy job - Invoke pipeline - Web - Azure Databricks  - WebHook - Functions - Azure HDInsight  - Azure Batch  - Azure Machine Learning ... View more

It would be super helpful to get a connection string in SSMS with the workspace name instead of the very cryptic string you get today : Imagine being able to see: server name : WorkspaceNameDev server name : WorkspaceNamePrd That would greatly improve this experience. I know that you can manually rename them in SSMS, but that is not really good in a larger team setting and makes onboarding of new developers a pain. ... View more

Hi,   The new Office 365 Email Fabric Connection that is required to run a new Office 365 Email in an activity using Service Principal authentication cannot be shared. I get that should be the case for OAuth authentication connections with individual user accountsfor security reasons.   New Office 365 Email Activity         This causes us issues becasue we are using git and branched workspaces. If a connection is not shared with other workspace users then when people branch out to their workspace, artifacts with unshared connections cannot load. Hence, why we are still using the old Email activities. I've just noticed today that the old Email activity is no longer available in pipeline activitiy options. When will the legacy version be going completely, please? And before it goes, will there be any updates to the new Email connection to make it sharable? In the mean time, are there any other options?   Thanks. ... View more