Clone a workspace, including its data, to a new workspace
Description: Today there's no way to fully clone a Fabric workspace: git sync and Deployment Pipelines move item definitions only, not the underlying data; Warehouse's zero-copy CREATE TABLE ... AS CLONE OF explicitly doesn't work across workspaces; and the Fabric CLI's recursive workspace copy (fab cp -r) copies items one by one, not warehouse row data. This is a real gap for teams running feature-branch or test workspaces provisioned from git — after standing up a new workspace, we have to hand-build separate pipelines/notebooks just to reload representative data, because there's no platform-native "clone with data" step. This is exactly the scenario dbt-style dev/test/prod parity workflows need too. Ask: a first-class "Clone workspace" action (portal, REST API, and Fabric CLI) that provisions a new workspace with both: All item definitions (as git sync/Deployment Pipelines already do), and Their underlying data — Lakehouse Delta tables/Files (likely straightforward via OneLake), and Warehouse table data (even a physical copy would help, given cross-workspace zero-copy clone isn't supported). This would remove the need for bespoke data-reload pipelines every time a team needs a fully working, data-populated copy of a workspace for testing or development.
Parameterize Dataflow Gen2 data source connection
Allow the Dataflow Gen2 data source connection GUID to be parameterized and stored in a Variable Library. This would allow the same Dataflow to use different connections depending on the workspace/environment, without modifying the Dataflow itself. Hypothetical example: Variable Library: SourceConnectionGuid = 01234567-89ab-cdef-0123-456789abcdef The Dataflow references this variable for its data source connection. In another workspace, the same Dataflow could use: Variable Library: SourceConnectionGuid = fedcba98-7654-3210-fedc-ba9876543210 This would make it much easier to use the same Dataflow across personal feature workspaces, test, and production while keeping the appropriate connection for each environment.
Make Prep Data for AI Deployable Across Fabric Environments
Idea Fabric Deployment Pipelines should consistently promote all Prep Data for AI settings with semantic models, including: AI Instructions Verified Answers AI schema and field selections Today, deploying from Dev to UAT or Production can remove, reset, or inconsistently transfer these configurations. Git/TMDL updates may also cause AI Instructions to return blank. Why this matters Without reliable deployment, companies must manually recreate and validate AI configurations in every environment. This: Breaks standard CI/CD processes Creates inconsistent Copilot responses Introduces governance and production risks Prevents enterprise-scale adoption Requested improvements Full Prep Data for AI support in Deployment Pipelines REST APIs to read and write the configuration Reliable Git and TMDL integration Deployment validation for missing or changed AI settings Microsoft Support has indicated that the feature is still in Preview, so support and workarounds are currently limited. Enterprise customers need a scalable, auditable deployment process—not manual configuration in each workspace. If your organization uses separate Dev, Test, and Production environments, please vote. This capability is essential for making Fabric Copilot enterprise-ready.
Allow selecting specific Fabric items to pull when using Update from Git
I’d like to suggest adding selective item deployment to Microsoft Fabric’s Update from Git experience. Today, when a Fabric workspace is connected to Git, Update from Git is primarily focused on synchronizing the workspace with the connected branch. In larger solutions, however, teams often do not want to deploy every changed item at once or we want to handle dependencies between items since Fabric is not reliable with dependencies. For example, a branch may contain changes to: Notebooks Data pipelines Lakehouses Warehouses Semantic models Reports In some cases, I may only want to promote a subset of those changes into Test or Production. It would be useful if Update from Git allowed users to: Select which Fabric items to update from Git. Preview the changes for the selected items before deployment. See dependencies for the selected items. Optionally include required dependencies automatically. Warn when a selected item depends on another changed item that has not been selected. Leave unrelated changed items untouched in the target workspace. Support the same selective behavior through APIs for automated CI/CD scenarios. This would give teams much more control over promotion between environments. For example, if a Git commit contains changes to a notebook, pipeline, semantic model and report, a team may want to deploy only the notebook and pipeline to Production while keeping the semantic model and report changes for a later release. Adding selective Update from Git would make Fabric Git integration much more flexible for real-world CI/CD processes, especially for larger solutions where many Fabric items are maintained in the same workspace and Git repository. This feature would work particularly well together with dependency-aware Git deployment, where Fabric could identify what additional items are required when a user selects an item for deployment.Dependency-aware Update from Git operations
I’d like to suggest improving Update from Git in Microsoft Fabric so that it becomes more dependency-aware during deployments. Git deployment can become fragile when multiple Fabric items depend on each other. For example, a workspace may contain: Data pipelines Notebooks Lakehouses Warehouses Semantic models Reports Connections or environment-specific references When using Update from Git as part of a Dev → Test → Prod deployment process, Fabric should ideally understand the dependency graph between these items and deploy them in the correct order (for example if report is connected with lakehouse, first deploy the lakehouse and then the report). It would be very useful if Update from Git could: Automatically detect dependencies between Fabric items. Determine the correct deployment order based on those dependencies. Validate dependencies before applying changes, including missing or unresolved references. Clearly identify dependencies that cannot be automatically rebound, such as certain cross-workspace references or environment-specific connections. Show a pre-deployment dependency report explaining what will be created, updated, rebound, or left unresolved. Ideally support transactional deployment or rollback if a dependency-related failure occurs. The goal would be for a Git commit to represent a deployable state of a Fabric solution, rather than requiring teams to manually manage deployment order and dependency resolution outside Fabric with custom solutions and scripts. This would make Git-based CI/CD significantly more reliable and reduce the need for custom scripts and manual deployment logic. It would be especially valuable for larger Fabric solutions where notebooks, pipelines, lakehouses, warehouses, semantic models and reports form a dependency chain. This would make Update from Git much more suitable as a production deployment mechanism for Microsoft Fabric.Semantic model connection bindings should be in source control (Git)
Semantic model data source connection bindings should be source controlled. A semantic model can contain multiple data source references, each of which can be mapped to a separate Fabric data connection. Currently, the semantic model definition is source controlled, but these data source → connection bindings are not. After a Git sync or deployment, the connections therefore have to be mapped to the semantic model again, either manually through Semantic model settings → Gateway and cloud connections → Maps to, or programmatically using the connection binding API. The connection bindings should instead be included in the source-controlled semantic model definition and automatically applied during Git sync and deployment. Preferably, the connection ID should also support Variable Library variables. Since the connection is identified by a GUID, the binding could accept a String/GUID Variable Library value, allowing the same semantic model definition to be used across environments with different connections. The Variable Library would then provide the appropriate connection IDs for each environment. This would eliminate the need for separate manual or programmatic connection-binding steps after Git synchronization or deployment.
Access Variable Library in Semantic Models
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.Deployment pipeline: Deployment rules for Direct Lake on OneLake semantic models
Currently, it is not possible to use deployment rules with Direct Lake on OneLake semantic models. The option is greyed out. Please enable this, so we can automatically change the data sources when deploying from dev to prod.
Deployment Pipelines - Remember selected stage
Every time we go into a deployment pipeline, it defaults to selecting the Development stage. I believe that it would be very rare to have a user select the Development stage. It would be helpful if deployment pipelines remembered which stage I had selected before as the target.Improve CI/CD consistency for Microsoft Fabric Real-Time Intelligence Eventstreams
Microsoft Fabric Real-Time Intelligence has made strong progress with Git integration and deployment pipelines, but lifecycle management can still be inconsistent across Eventstream sources, destinations, connections, and deployment scenarios. I would like to see more consistent CI/CD support across Real-Time Intelligence artifacts, including automated environment-specific connection rebinding, easier promotion from development to test and production, deployment validation before activation, and clearer diagnostics when an RTI artifact cannot be promoted successfully. For enterprise implementations, it would also be valuable to reduce the amount of manual reconfiguration required after deployment. Improving these capabilities would make Real-Time Intelligence solutions easier to operationalize, govern, automate, and teach as production-ready architectures rather than solutions that require manual configuration between environments.
