This post covers native vs custom branching out in Microsoft Fabric, where I compare Microsoft Fabric’s native branching out options with the custom Branch Out to New Workspace scripts made available by Microsoft.
I decided to write this post after Microsoft introduced the new branch workspace admin configuration options in Microsoft Fabric, which are currently in preview.
Just to recap, some time ago Microsoft introduced custom Branch Out to New Workspace scripts for Microsoft Fabric, which allow you to automate the “Branch out to new workspace” functionality with Azure DevOps.
You can find the scripts in the Fabric Toolbox GitHub repository provided by Microsoft. I previously wrote a post that covers how to get started with the custom branch out to new workspace scripts if you want to see how they work in more detail.
Testing branch workspace configuration options in Microsoft Fabric
I wanted to show that the new branch workspace configuration options worked before drawing up my comparisons. I did this by configuring the settings as shown in the image at the start of this post and then branching out to a new workspace whilst logged in as a regular user.
Once the branch out had completed, I then checked the workspace settings.
My regular user account was indeed only a Contributor in the new feature workspace, which limited what they were able to do. I confirmed this by going into the new feature branch as an administrator and checking the workspace access.
These new branch workspace configuration options make branching out natively in Microsoft Fabric a lot more appealing.
Because you can now allow regular users to create new feature workspaces without excessive permissions. In addition, the ability to add other accounts as admins and change capacities will bring a lot of benefits. Such as adding service principals to new workspaces by default.
Native vs Custom Branching Out in Microsoft Fabric
The new branch workspace configuration options make branching out natively in Microsoft Fabric a much more compelling option. However, how does branching out natively compare to the scripts provided by Microsoft?
Below is a table comparing their main default capabilities.
| Capability | Native | Custom scripts |
| Name the new workspace/branch | ✅ | ✅ |
| Branch to existing workspace | ✅ | – |
| Add default user role | ✅ | – |
| Add an administrator | ✅ | ✅ |
| Add multiple administrators | ✅ | – |
| Set destination capacity | ✅ | ✅ |
| Select individual items | ✅ | – |
| Switch branches dynamically | ✅ | – |
| Checkout branch separately | ✅ | – |
| Automatic rebinding | Limited/depends on functionality | ✅ |
| Copy Lakehouse/Warehouse data | – | ✅ |
| Creates shortcuts in local Lakehouse pointing back to tables in the source Lakehouse | – | ✅ |
| Swap pipeline connections | – | ✅ |
| Extend/customise behaviour | Limited | ✅ |
Bear in mind that the new branch workspace configuration options are currently in preview and the above table is subject to change.
Another key point relates to the defaults that come with the custom branch out scripts. In reality, you can extend these scripts however you see fit. For example, add the ability to add multiple administrators.
Epilogue
After reading about the native vs custom branching out in Microsoft Fabric the big question is which do you want to work with?
In reality, both options have their advantages, and I can see the benefits of both in different scenarios.
Working with the native options in Microsoft Fabric has become an even more compelling option thanks to the new branch workspace configuration options. They provide a straightforward way to control who can branch out and how the resulting workspaces are configured, without requiring external automation.
One thing I would like to see appear in the native branch out functionality is the ability to rebind certain items by default.
On the other hand, the custom branch out scripts remain a fantastic option for those who require automatic rebinding’s or some of the other functionality they provide. They also give you the flexibility to extend the scripts however you see fit to meet your own requirements.
Whichever you decide to work with, I hope this post has helped raised awareness about both of these offerings.