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

Hello,   it would be great to have a option to set a parameter for how much jobs (actually table copy activities) can be started in parallel. This would allow the user to overcome issues for example to overload on-prem datagateways with to much parallel jobs so that the gateway goes down. Currently this is not possible and Fabric "steers" the job by itself which might lead to gateway overload.   PS: yes that might not be the case for incremental loads but for first initial full loads this would come handy.   Thanks! ... View more

DataFlow Gen2 cannot be triggered using a service principal which is crucial and necessary for companies using the officially supported and joined project fabric-cicd which is a library to deploy workspace items via the official REST API. Because Microsoft did disable deployment using normal user accounts, recommending Service Principals for that, everything is deployed and therefore owned/modified by the same Service Principal. This leads to the obvious problem that pipelines trying to call/refresh DataFlow Gen2 will faile because refresh via SP is not supported. This is a very frustrating situation to be in because normal user deployment was disabled without thinking about the crippling of functionality like this. ... View more

Pipeline schedules should not have an end date by default.   The current 1-year default end date introduces a hidden failure mode where pipelines silently stop running.   Most pipelines are intended to run indefinitely, so this default creates unnecessary operational risk and maintenance overhead.   Removing the default end date would make scheduling more reliable and predictable, while avoiding unexpected disruptions. ... View more

The request is to ensure Schedules are not included in the definition of a Data Pipeline for purposes of Deployment Pipelines.   Today, when we deploy content across environments, the item frequently appears as “different” because the schedule configuration is included in the comparison. This creates constant noise and makes it harder to identify meaningful differences.   More importantly, a schedule configured in DEV or TEST can be promoted into PROD as part of a deployment. This creates a real operational risk and is unacceptable — PROD scheduling must be managed independently and explicitly, not carried over from lower environments. ... 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

Hello team,   First of all, I believe this is a very positive step towards bringing Azure Data Factory closer to the Microsoft Fabric ecosystem and enabling a smoother adoption for customers.   From my perspective, and as an opportunity for improvement, the term “migration” may create certain expectations that do not yet fully align with the current experience.   At the moment, this functionality feels more like the integration or connection of existing ADF elements into Fabric, which already provides significant value in terms of transition and visibility. However, a logical next step in this evolution would be a deeper integration within Fabric, both from an operational perspective and in terms of the consumption model. In this sense, greater alignment in this direction could help the experience better match the concept of a full migration and provide more clarity to customers during their adoption journey. Proposal I see two options that could be very valuable: Maintain the current experience, but associate the cost with Fabric If the current “migration” experience remains similar to what it is today, it would already be very valuable if, once these elements are brought into Fabric, their consumption and cost were associated with Fabric capacity instead of continuing to reside in the Azure subscription. From my perspective, this would already be a significant step forward because it would: Centralize costs within Fabric Reduce the perception of operating across two separate platforms Reinforce Fabric’s value as a unified platform        2.Maintain the same experience, but allow customers to choose where the cost is allocated A second, more flexible option would be to allow customers, during this “migration” or onboarding experience, to choose between: Cost allocated to Fabric Cost allocated to the Azure subscription This would enable a more gradual transition and provide customers with greater flexibility based on their adoption strategy. Motivation If this experience is primarily designed for customers who already have elements in Fabric but still depend on ADF, then in practice there are still silos in place. That is why, to me, the current experience feels more like a shortcut rather than a true migration. And that is the key point: a real migration should mean that the asset: Is integrated into Fabric Is operated from Fabric Consumes Fabric capacity In my opinion, that would be the ideal next step for the product. Ideal end state My ideal vision would be a full migration to Fabric, where ADF elements truly become native Fabric assets, or at least run entirely within Fabric with their cost associated to Fabric. I believe this would have a strong impact on adoption, because it would no longer be about simply surfacing or referencing existing assets, but actually moving workloads, operations, and the consumption model into Fabric. Closing In summary, my suggestion would be: As this experience continues to evolve as a “migration”, there is an opportunity to further align it in terms of execution and cost model. As an intermediate step, allow the current experience to associate costs with Fabric. And as an additional option, allow customers to choose whether the cost is assigned to Fabric or to the Azure subscription. I believe this would better align the expectations created by the announcement with the actual value customers expect from a migration to Fabric. I would be happy to share more detailed use cases if helpful. Thank you for your continued innovation. ---------------- Hola, equipo,   En primer lugar, creo que este es un paso muy positivo para acercar Azure Data Factory al ecosistema de Microsoft Fabric y facilitar una adopción más fluida para los clientes.   Desde mi punto de vista, y como una oportunidad de mejora, el término "migración" puede generar ciertas expectativas que aún no se ajustan completamente a la experiencia actual.   Actualmente, esta funcionalidad se asemeja más a la integración o conexión de elementos ADF existentes en Fabric, lo cual ya aporta un valor significativo en términos de transición y visibilidad. Sin embargo, un siguiente paso lógico en esta evolución podría ser una integración más profunda dentro de Fabric, tanto desde el punto de vista operativo como en lo que respecta al modelo de consumo. En ese sentido, una mayor alineación en esta dirección podría ayudar a que la experiencia se ajuste mejor al concepto de migración completa y proporcionar mayor claridad a los clientes durante su proceso de adopción.   Propuesta Veo dos opciones que podrían ser muy valiosas: Mantén la experiencia actual, pero asocia el costo con la tela. Si la experiencia de "migración" actual se mantiene similar a la de hoy, ya sería muy valioso que, una vez que esos elementos se incorporen a Fabric, su consumo y coste se asocien a la capacidad de Fabric, en lugar de seguir residiendo en la suscripción de Azure. Desde mi punto de vista, esto ya sería un gran paso adelante porque: Centralizar los costos dentro de Fabric Reducir la sensación de seguir operando en dos plataformas separadas. Reforzar el valor de Fabric como plataforma unificada Mantén la misma experiencia, pero permite que los clientes elijan a qué se asigna el costo. Una segunda opción, más flexible, sería permitir a los clientes, durante esta "migración" o experiencia de incorporación, elegir entre: Costo asignado a la tela Costo asignado a la suscripción de Azure Esto favorecería una transición más progresiva y ofrecería a los clientes una mayor flexibilidad en función de su estrategia de adopción.   Motivación Si esta experiencia está diseñada principalmente para clientes que ya tienen elementos en Fabric pero que aún dependen de ADF, entonces en la práctica siguen existiendo compartimentos estancos. Por eso, para mí, la experiencia actual se parece más a un atajo que a una verdadera migración. Y ese es el punto clave: una migración real debería significar que el activo: está integrado en Fabric, es operado desde Fabric, y consume capacidad de Fabric. En mi opinión, ese sería el siguiente paso ideal para el producto.   Estado final ideal Mi visión ideal sería una migración completa a Fabric, donde los elementos de ADF se conviertan realmente en activos nativos de Fabric, o al menos se ejecuten completamente dentro de Fabric, con su coste asociado a Fabric. Creo que eso tendría un fuerte impacto en la adopción, porque ya no se trataría solo de mostrar o hacer referencia a los activos existentes, sino de trasladar realmente la carga de trabajo, las operaciones y el modelo de consumo a Fabric.   Cierre En resumen, mi sugerencia sería: As this experience continues to evolve as a ‘migration’, there is an opportunity to further align it in terms of execution and cost model. Como paso intermedio, permita que la experiencia actual asigne un costo a la tela. Y como opción adicional, permita a los clientes elegir si el costo se destina a Fabric o a la suscripción de Azure. Creo que esto alinearía mucho mejor las expectativas generadas por el anuncio con el valor real que los clientes esperan de una migración a Fabric.   Con gusto compartiré casos de uso más detallados si resulta útil.   Gracias por su continua innovación. ... View more

We are right now using scrript activities to call the sql transformation scripts placed on  Azure Blob. We want Data Factory script activity to read the sql transformation script from Azure Git Repo ... View more

We need support for Service Principal authentication when creating Lakehouse connections.   Right now, Lakehouse connections can only be created using a user account. As a result, Dataflow Gen2, Pipeline copy activity, and Copy Job cannot use a Service Principal (SPN) when connecting to a Fabric Lakehouse as a source or destination.   This is an issue for us. We want to avoid user-based connections because: We need environment-specific identities (dev/test/prod) to prevent accidental cross-environment writes (e.g., dev pushing data to prod). Tying connections to personal user accounts creates fragility - things break when someone leaves the project or the organization. Service Principal support for Lakehouse connections is required to ensure secure, reliable, and environment-isolated authentication.   The screenshot shows that only user authentication is available, not service principal authentication. ... View more

Similar to the Monitor page, where we can see what has run and what is currently running, it would be useful to see what's scheduled to run in the future. This to check that all schedules are set up as expected.   Reason: Easy and conveniently verify that all schedules are configured as expected. ... View more

Today, only Oauth 2.0 (user account) is supported as authentication option when setting up an Azure Key Vault reference.   Please add support for Workspace Identity  Service principal User assigned managed identity ... 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

Currently, with the new multiple scheduler feature, we can define multiple run schedules for a Fabric item. However, when using deployment pipelines, there’s no way to control which schedules are active in Dev, Test, or Prod. This means schedules intended only for Prod must also run in Dev, consuming unnecessary compute.   It would be very useful to allow using the Variable Library or deployment rules to set the active/inactive state of each schedule per environment, making deployments more efficient and flexible. ... View more

its well known that intellisense has always been broken with things like ListList.Contains or pressing . after typing certain prefixes does not correctly show options, or typing null enter puts null.type in. Also a huge issue is no intellisense in Dataflows both need fixing ... View more

  Make it possible to create custom views in the Monitor tab Optionally select: Domain(s) Capacity(s) Workspaces Item types Item names Selections for domain names, capacity names, workspace names or item names can also look for names that contain certain substrings (or even regex) Make it possible to send a daily summary e-mail to specified recipients Group email addresses  Individual email addresses  Daily summary e-mail contains: Count of failed runs (and list of failed items) Count of successful runs Total duration of runs  Workspace Viewer permission should be sufficient to include a workspace in alerting.   It would also be great if we could use Workspace Identity or Service Principal for setting up the monitoring view (monitor view can read execution details from all workspaces the SPN is at least viewer in).   Alerts could be sent from the "Fabric Service" (instead of individual user as sender) to look more professional.   A Monitor View could be shared, so that colleagues could collaborate on owning and editing a Monitor view. ... View more

Please add support for mirroring to OneLake from on-premise SQL Server. ... View more

Testing out the new pipeline activity "Lakehouse maintenance". I cannot select a table name. Cannot even specify dynamic content that returns a table that I KNOW is in the lakehouse.   This is broken. Yes, I understand it is in preview, but honestly, it needs to be more stable if I can break it in 2 minutes. ... View more

The ability to parameterize the connection would enable using separate identities (e.g. separate service principals) for dev/test/prod environments.    Having to use the same SPN in dev/test/prod introduces unnecessary risks, like accidental data modification across environments - a dev workload accidentally writing to production data, or a production workload accidentally connecting to and using data from the dev environment.   This would be solved if we could use variable library to reference the corresponding connection id for dev/test/prod service principal.   Unfortunately, the connection property in pipeline's notebook activity does not support Dynamic Content yet.   Please make this possible so we can avoid the risk of cross-contamination between environments. ... View more

Enable to modify the mashup document of a Dataflow Gen2 by passing a variable from a pipeline before an execution of the Dataflow ... View more