Fabric Copy Jobs desperately need basic editability after creation.
Requiring users to recreate an entire Copy Job just to change something as fundamental as the source connection or connection URL is unnecessarily restrictive and creates significant maintenance overhead. A Copy Job should allow users to: Change the source connection Change the destination connection Edit connection details Repoint a job to a replacement connection Preserve existing mappings, scheduling, and other configuration when changing connections Having to rebuild a working job because one connection property needs to change makes Copy Jobs much less useful for production data workflows. Please add the ability to edit or replace connections on an existing Copy Job.
Have an optional field for storage container when connecting to Azure Blob
I'm trying to set up an Azure Blob connection as I'm trying to pull data from Snowflake and land them into my storage. Due to Snowflake only supporting Blob APIs, the DFS endpoint isn't an option for me. My organisation admin only allows us to create a SAS token on the storage container level, however when creating a Blob connection, it's asking for a SAS token for the storage account instead. Can Microsoft consider having a container level SAS token instead for Blob connections?
Portable Library of Queries (Functions)
Currently, a custom connector requires a Data Source and a Authentication record associated to a function in order to be Published or exposed in the 'Get Data' dialog/window. This is perfectly fine for data sources, but if I want to create a custom connector that creates data using native M functions, like. List.Generate or List.Dates, then I shouldn't have to define a Data Source nor an Authentication which complicates things and is an unnecessary step for the end user. Here are 2 videos showcasing 2 functions that do not need any sort of authentication, but due to the way custom connectors currently need to be constructed, they get prompted for credentials as an "Anonymous" user: https://youtu.be/76W1Cu1qSfw https://youtu.be/Q06NKl8A4eI The idea: to remove the need for a DataSource/Authentication record for custom connectors that act as library of functions so they can be published on the 'Get Data' dialog and not only shared as environment variables.
Add name and description to Item Schedule
A Fabric item can now have up to 20 schedules attached to it. These schedules can have different purposes, let's say one is for nightly runs and another one is for runs during working hours. If we want to update a schedule via API, we need the schedule ID. To get the ID, we can list the schedules. But, there's no easy way to pick the relevant schedule from the returned list or schedules - because there's no name or description associated with a schedule object. Please add the option to create a name or description for an item schedule. This could also show up in the run log of an item (run was triggered by schedule [Name]) which would provide useful context for the run. It could also be cool if an item could pick up the schedule name as a "TriggeredBy" property and potentially execute conditional logic depending on which schedule triggered the run.Workspace Classification and simplification
Hello, At the level of an organization, managing a lot of Workspaces become quickly an issue. Here are few ideas to help improving this: - Be able to label a workspace as development or UAT - Be able to link the workspaces between them and having a hierarchy of workspaces - Be able to publish only in Dev workspaces, UAT and Prod must be accessible only using pipelines - Having a master page that shows all the workspace I have access to with the link to the related Application (Or at least having only the list of applications and the list of Reports (Audience linked). Both builders and users experiences need to be improved to have a better use of Fabric platform. Regards, HichamAPI to check that e-mail 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 e-mail list for Failure Notifications 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-runs
Power Query Schema View - width of column "Name"
While working with the Schema view in Dataflow, the width of column "Name", which lists the name of the columns in the query, is fixed. Due to this it only shows initial about 19 characters of the column name. When there are multiple columns with commone first ~20 characters, it becomes difficult to know the right column and the only way to see full column name is to hover mouse pointer over the row with the column name. Due to this the utility of the schema view is greatly reduced, as a simple task of correcting the Type takes a long time. One needs to hover over each column to see the full name and accordingly change the Type. Please make the width of the column "Name" in Schema view adjustable, or make it enough to show at least 40 characters of the column name. This will enable users to quickly change the Type of required columns.Built a free tool to inventory & risk-rate legacy SSIS packages before a Fabric migration
Hi all, Sharing something I built that might save some of you the painful "open every .dtsx in SSDT one by one" phase of an SSIS → Fabric migration. The problem it addresses: most teams sitting on a legacy SSIS estate have dozens to hundreds of undocumented packages and no clear starting point. Before any actual migration work, someone has to answer: what does each package do, which components map cleanly to Fabric, and which need a full rewrite? What it does: Parses .dtsx package XML and extracts control flow tasks, data flow components, connection managers, variables, and precedence logic Maps each component against a Fabric equivalent — Data Flow Task → Dataflow Gen2, Execute SQL Task → Script/Stored Procedure Activity, Script Task → Notebook Activity, Foreach Loop → ForEach Activity, and so on Gives each package a Low/Medium/High risk rating based on concrete signals (Script Task usage, Fuzzy Lookup, deprecated CDC/Attunity components, nesting depth, dynamic connection strings) Flags every component individually as auto-mappable or needs-manual-redesign, not just the package as a whole Across a batch of packages, produces a portfolio rollup: risk tier counts, the blockers showing up across the most packages, deprecated components flagged separately, and a suggested migration order What it's built as: a Claude Skill (Anthropic's Claude AI), with the actual XML parsing done by a plain Python script with zero dependencies — not an LLM guessing at package structure. It's designed to run fully offline, no live Azure/Fabric API access assumed, though it flags anywhere that access would improve accuracy (resolving a dynamic connection string, for example). What it deliberately doesn't do yet: this covers the Inventory/Classify phase only. It won't draft actual Fabric pipeline JSON or claim a package is production-ready — every future draft artifact gets an explicit DRAFT/NEEDS REVIEW label. I'd rather it under-claim than over-claim. Repo's on GitHub with a sample package and example report included, so you can see the actual output before running it against your own packages: https://github.com/HBBH11/ssis-fabric-migration-assistant Genuinely interested in feedback from people who've done these migrations for real — particularly whether the risk heuristics hold up against messier packages than my test case, and whether the Fabric equivalence mappings match what you've found in practice. Happy to take suggestions on what a Phase 2 (draft pipeline generation) should prioritize too.Pipeline: Activity-level Run Conditions (No IF Container Required)
We need the ability to add a "Run if" condition directly to every pipeline activity. Like, in each acticity's settings. One of the biggest readability issues in Fabric Pipelines is that conditional execution requires wrapping activities inside an If Condition container. Instead of the big and visually annoying IF condition, I'd like every activity to have an optional Run if property, for example: * `variables.load_sales == true` * `pipeline().parameters.run_validation` * Any supported dynamic expression If the condition evaluates to false, the activity should simply be marked Skipped, and downstream dependency behavior should continue to work as it does today. This would make pipelines much flatter, easier to scan, and much less cluttered.Pipeline: New Routing activity as an improvement to IF and Switch
The current If Condition and Switch activities create large nested containers that own all activities inside their branches. These containers make the canvas much harder to read. Instead, add a lightweight Routing Activity. Pipeline activities already support four dependency conditions: On Success, On Failure, On Completion, and On Skip. The Routing Activity would extend this existing model by allowing users to add additional output branches, with each branch backed by its own dynamic expression. Examples: * `variables.load_sales` * `pipeline().parameters.run_validation` * `@equals(variables.region, 'EU')` When the Routing Activity runs, it evaluates each expression and only activates the downstream branches whose conditions are true. The key difference is that downstream activities stay on the main canvas instead of being nested inside a container. This would make orchestration pipelines much flatter, easier to scan, and significantly less cluttered while preserving the same execution logic.
