Pipeline CI/CD Improvement, Get Item ID activity from workspace ID and item name
Currently when following any branch strategy that requires a separate ephemeral feature (or other) workspace running a notebook from the same workspace requires too much ground work To find the ID of the notebook you need a way to call the APIs to GetItems in the workspace to find the correct ID of the notebook (or other item like the lakehouse), this is overly convoluted requiring API calls through web activity or separate notebook in a stand alone workspace with fixed ID that returns the item IDs in the pipeline's workspace Idea: add a pipeline activity that retrieves the item ID of an item using a workspace ID and item name or a function in pipeline expressions that allows the same to be done so this can be inlined without a dedicated pipeline activity.
Pre-Deployment Impact Analysis for Fabric Deployment Pipelines
Before deploying an artifact, Fabric should provide a complete dependency and impact analysis report. Features Show impacted reports, semantic models, notebooks, pipelines, and Lakehouses. Highlight breaking changes. Compare source and target environments. Identify deleted columns, measures, and tables. Generate deployment risk score. Benefit Prevents production failures and provides confidence before promotion.Enhance Fabric Deployment Pipelines with Environment-Aware Connection Rules for fabric CICD
Currently, Microsoft Fabric Deployment Pipelines do not fully support automatic environment-specific connection updates for Data Pipelines, Dataflows Gen2, Lakehouses, and Semantic Models. After promoting artifacts from Development to Test or Production, many connections continue to reference the source environment objects. For example: Data Pipelines continue pointing to the Development Lakehouse. Dataflows Gen2 retain references to Development data sources and destinations. Semantic Models built using Direct Lake (OneLake) continue referencing the original Lakehouse. Developers must manually update connections and dependencies after each deployment. This increases deployment effort and introduces the risk of errors and production issues. Proposed Enhancement Extend Deployment Pipeline Rules to support automatic connection mapping and environment-specific configuration updates for: Data Pipelines Dataflows Gen2 Lakehouses Warehouses Semantic Models (including Direct Lake / OneLake models) Notebooks and related dependencies Desired Capabilities Configure source-to-target artifact mappings once. Automatically replace Lakehouse references during promotion. Automatically update Dataflow source and destination connections. Automatically update Semantic Model Direct Lake connections. Support parameterized environment configurations. Centralized deployment rule management. Dependency-aware artifact remapping. Preview changes before deployment. Example When promoting from: DEV Lakehouse: Sales_DEV Semantic Model: Sales_Model_DEV To: TEST Lakehouse: Sales_TEST Semantic Model: Sales_Model_TEST Fabric should automatically update all dependent Data Pipelines, Dataflows, and Semantic Models to point to the corresponding TEST artifacts without requiring manual intervention. Business Benefits Reduces post-deployment manual rework. Minimizes configuration errors across environments. Accelerates CI/CD adoption in Fabric. Simplifies enterprise deployment processes. Improves governance and consistency. Enables true automated Dev → Test → Prod promotion. Reduces operational risk and deployment time. This enhancement would make Microsoft Fabric Deployment Pipelines significantly more enterprise-ready by providing comprehensive environment-aware connection management across all Fabric artifacts and dependencies.
Add Pre-Deployment Impact Analysis and Destructive-Change Warnings
Before deploying Microsoft Fabric items from Development to Test or Production, Deployment Pipelines should automatically perform a detailed impact analysis. The validation should identify: • Downstream reports, semantic models, notebooks, pipelines, and other dependent items that may be affected • Breaking schema changes, including removed columns or changed data types • Operations that could delete, truncate, or overwrite existing data • Missing connections, permissions, dependencies, or deployment rules • Configuration differences between source and target environments The results should be displayed with severity levels such as Information, Warning, and Critical. Administrators should be able to block deployments containing critical changes or require manual approval before proceeding. This feature would prevent broken reports, failed refreshes, and accidental data loss, making Fabric deployments safer and easier to manage.
Fabric > Dataflow Gen 2 > Destination: Allow this to be a dataflow parameter like table name can be
I recently disovered parameters in dataflow which was a big unlock in organization/efficiency, but not being able to specify the detination dynamically (outside of very end table name) nullifies that features' usefulness by having to make at least one per lakehouse because of this. Please update the Destination UI to allow a Parameter to be selected for the lakehouse (including folder/schema/dbo) to be populated by a dataflow parameter.
Automatically configure or deploy data source credentials as part of the Fabric CI CD process
Currently, Microsoft Fabric deployment pipelines support data source deployment rules for paginated reports, but this do not deploy or automatically configure data source credentials (including OAuth tokens or user authentication credentials) during deployment. This causes diffculty to automatically deploy the reports and manually had to update the source credentials.Fix the broken Diff Compare for Data Pipelines in Deployment Pipelines
The Compare view for Data Pipelines in Deployment Pipelines is all over the place. Nothing aligns between environments, even if there is no diff or only a small diff in reality. Please fix it - the Compare view works fine for other item types.Allow scheduler configuration with variable libraries
The new scheduler is a great idea (Unlocking Flexibility in Fabric: Introducing Multiple Scheduler and CI/CD Support | Microsoft Fabric Blog | Microsoft Fabric) However, the fact that we cannot control this using variable libraries means that if you have scheduled refreshed disabled in dev and test then after every prod deployment you have to renable the refresh. There is also no way to turn off this new scheduler and go back to the old scheduler which did not move across environments. Please either enable us to control the scheduler via depoyment pipelines ASAP or give us a tenant switch to disable this till this feature is supported.
Deployment Pipelines: preserve/override schedules per environment (no overwrite on deploy)
When deploying from Dev/Non-Prod to Prod, the target’s pipeline schedule is overwritten. Please add deployment rules (or an opt-out) so schedules can be environment-specific without showing as drift in comparisons. This avoids Prod cadence being reset and reduces capacity burn in Non-Prod.Interactively run notebook as Service Principal, Workspace Identity or Managed Identity
Please make it possible to interactively run a Notebook as a Workspace Identity, Service Principal or Managed Identity. Purpose: This would allow us to connect to resources that our personal user account doesn't have access to. This would allow us to interactively test notebooks using the Workspace Identity, Service Principal or Managed Identity before we include the notebook in a pipeline. This way, we could test: the identity's access to data sources and the notebook code's functional compatibility with running as SPN/WI/MI (because not all notebook functionality like semantic link is compatible with SPN, we'd like to be able to test this interactively before including the notebook in a pipeline).