Fabric Deployment Plans and Branch Workspaces

Navy Solv Systems title card reading 'Fabric Deployment Plans Explained' with a continuous loop motif.

In Short: The Fabric Deployment Plan Fills the Gap Lineage Could Not

Fabric CI/CD has had a recurring weak spot: some items must deploy in an order Fabric cannot see, and some deployments need work done in the middle. Deploy a lakehouse, run a notebook to create its tables, and only then deploy the warehouse views that read them. Until now that middle step lived on a checklist.

A Fabric deployment plan, announced in preview at FabCon Europe on 29 September 2026, puts it into the deployment itself. At the same time, Microsoft made the branch workspace features generally available: selective branching, compare and commit, and branch workspaces linked to their source. Together they give a cleaner path from a developer's feature branch to production in Microsoft Fabric.

This post explains both, how they combine, and the limits worth knowing before you rely on them.

What a Fabric Deployment Plan Is

Microsoft Learn describes a deployment plan as "a workspace item that adds explicit item order and automated actions to a deployment operation". You build it on a canvas from three parts:

Deployment group - one item to deploy plus its actions
Step - the deployment of that item
Action - a run of another item before or after the group's item deploys

Five item types can run as actions: notebook, data pipeline, Dataflow Gen2, copy job and user data function. Actions in a group can be chained, take parameters, and those parameters can reference a Variable Library so one plan supplies different values per environment.

Fabric still works out dependencies from lineage. The plan adds order that lineage cannot represent; it does not remove dependencies Fabric detects. Selected items that are not in any group deploy as normal.

You never run a plan by itself. You attach it to a deployment operation, and Learn lists where:

Branch out to a new workspace
Initial sync of a Git connection
Update from Git, or switch branches
Deploy between deployment pipeline stages
Three REST APIs: Update From Git, Deploy Stage Content and Bulk Import Item Definitions

For the APIs, the plan goes in as a deploymentPlan object inside the existing options, the URL needs beta=true, and the token needs the Item.Execute.All scope on top of the operation's usual scope.

The Limits That Shape How You Use It

These come straight from Microsoft Learn's considerations, and several will change how you design a release:

No rollback. The operation stops at the first failure. Items already deployed stay deployed; later ones do not. Actions need to be safe to re-run.
Sequential only. Independent deployment groups do not run in parallel, and actions run one at a time.
Actions do not wait for downstream services. An action completes when it ends, so the next one can start before its data is queryable. Build a validation step rather than assuming.
No workspace configuration. A plan does not deploy workspace identities, connections, gateway bindings or Spark settings. Set up the target first.
Variable Library value sets are not switched. References resolve against whatever value set is already active in the target.
One plan, one target workspace, per operation. Attachment applies only to that operation; you cannot make a plan the default.
fabric-cicd does not support deployment plans. This one matters for teams standardised on the open-source library.

Size limits are generous: up to 1,000 groups, 20 pre-deploy and 20 post-deploy actions per group, and a 1 MB plan.

Branch Workspaces, Now Generally Available

Branch out has been Fabric's answer to "where does a developer work on a feature branch?" since we wrote our CI/CD and Git guide. From the Source control pane, branch out creates a Git branch and a workspace connected to it, linked to the source workspace so the relationship shows in the workspace tree.

The September 2026 Fabric feature summary lists as generally available:

Branch workspaces - branch out, switch and check out now live in the main Source control pane
Selective branching - branch out with only the items you need, with the dependency calculation running in the background
Compare and commit - inspect what changed between workspace and branch, side by side, before you commit or update

One small inconsistency: the branch-out page on Learn still labels "Select items individually" as preview in its deployment plan section, while the feature summary calls selective branching GA.

Still in preview: file-level commit (commit one finished view in a warehouse and leave the rest) and the branch workspace admin profile. The admin profile is the governance piece. A workspace admin sets the role developers get, the admins, the capacity, and whether contributors can switch branches. Fabric then creates the workspace, assigns capacity, connects Git and adds members on that admin's behalf. Developers no longer need rights to create workspaces or assign capacity. Note that the admin who last saves the profile becomes the identity every branch-out runs under.

The bulk export and import item definition APIs are also GA, and Microsoft says the fabric-cicd bulk option built on them is now production ready.

The Pattern We Are Moving To

Putting the pieces together, this is the shape we now recommend for Fabric teams of more than two or three developers:

Main workspace connected to the main branch, with a branch workspace admin profile once you are comfortable with preview
Developers branch out selectively, taking only the items they are changing and their dependencies
A deployment plan committed to Git alongside the items it references, so branch out itself can hydrate the new workspace - a notebook populating the lakehouse before dependent items arrive
Pull requests reviewed in the Git provider, helped by the PBIR format for readable Power BI diffs
Deployment pipelines promoting to test and production with the same plan attached, plus deployment rules for environment-specific settings

If you are already on fabric-cicd, keep it for the deployments that do not need ordering or actions, and use the native APIs with a plan where you do. Do not rebuild a working pipeline just to adopt a preview item.

Governance sits alongside this. If you want to stop ad-hoc item creation in production workspaces while developers self-serve branches, Microsoft Fabric policies are the matching admin control, and our FabCon Europe 2026 recap covers the rest of what shipped.

Where Solv Systems Comes In

We design Fabric delivery setups that survive a team growing: Git structure, branch workspace profiles, deployment plans for the awkward dependencies, and pipelines with rules that keep production settings intact. If your release still depends on someone remembering to run a notebook, our Microsoft Fabric consulting team can turn it into one repeatable operation.

Sources and Further Reading

Frequently asked

A preview workspace item that adds explicit item order and automated actions to a deployment. You build it on a visual canvas as deployment groups, each deploying one item, with notebooks, data pipelines, Dataflow Gen2 items, copy jobs or user data functions running before or after that item deploys. You attach it to a Git, deployment pipeline or API operation rather than running it on its own.

Microsoft Learn lists branch out to a new workspace, initial sync of a Git connection, update from Git or switch branches, deployment between pipeline stages, and three REST APIs: Update From Git, Deploy Stage Content and Bulk Import Item Definitions. Only one plan can be attached to an operation.

No. The operation stops at the first failed item or action and does not roll back completed work. Items that already deployed stay in the target workspace and later items do not deploy, so design actions to be safely re-runnable.

Not currently. Microsoft Learn states the fabric-cicd library doesn't support deployment plans. If you need a plan in automation, call Update From Git, Deploy Stage Content or Bulk Import Item Definitions with the deploymentPlan option.

Microsoft's September 2026 Fabric feature summary lists branch workspaces, selective branching, and compare and commit as generally available, alongside the bulk export and import item definition APIs. File-level commit and the branch workspace admin profile are in preview.

It lets a workspace admin preconfigure how branch workspaces are created - the developer's role, the admins, the capacity and whether contributors can switch branches. Fabric then creates the workspace, assigns capacity, connects Git and adds members on the admin's behalf, so developers do not need permission to create workspaces or assign capacity. It is in preview.