# Track Changes in Power BI: Part 3 - Workspace Mode

> Using Tabular Editor 3 & Workspace mode, source control is that much easier, even when using Branching!In this article, I explain how workspace mode in Tabular Editor 3 makes Source Control easy by letting you simultaneously save changes to disk but also to a service dataset for testing. I then explain how this can work when collaborating on a model, for example, using Git Branching in Power BI development.

- URL: https://data-goblins.com/version-control-pt3
- Author: Kurt Buhler
- Published: 2022-02-01
- Topic: Admin and governance

# RAMP UP PRODUCTIVITY WITH WORKSPACE MODE

*…and how to set up a **branching strategy** with Power BI Development*

---

<figure class="dg-figure"><img src="https://images.data-goblins.blog/2025/12/version-control-pt3-branching.png" alt=" Take the next steps to facilitate a more robust source control management (SCM) process "><figcaption>Take the next steps to facilitate a more robust source control management (SCM) process</figcaption></figure>

---

## CONTENTS

- ### **Part 1: Source Control in Power BI using Tabular Editor & DevOps** 

  - [**Intro:** Source Control & saving as Tabular Editor folder structure](https://data-goblins.com/power-bi/version-control/#intro)

- ### **Part 2: Getting it done**

  - [**Set-up:** Creating your first Repository with Azure DevOps & Git](https://data-goblins.com/power-bi/version-control-pt2/#setup)

  - [**Tutorial:** Power BI model source control with TE folder structure](https://data-goblins.com/power-bi/version-control-pt2/#tutorial)

  - [**Overview:** The Final Workflow](https://data-goblins.com/power-bi/version-control-pt2/#workflow)

- ### **Part 3: Next Steps**

  - [**Streamlining the Process:** Tabular Editor 3 & Workspace Mode](https://data-goblins.com/power-bi/version-control-pt3/#workspace)

  - [**Collaborative Effectively:** Using branching & SCM with Power BI data models](https://data-goblins.com/power-bi/version-control-pt3/#branching)

---

**In the previous post, we learned:**

- How to create an Azure DevOps Repo for Power BI source control
- How to clone the Repo using a Git (integrated) client like Visual Studio
- How to save the TE folder structure to the Local Repo, and commit/push changes to the Remote Repo
- How to use the TE folder structure for development in your new workflow

***Next up:** Find out how to make your **workflow & collaboration more productive** with Tabular Editor 3 (TE3) and **Workspace Mode**, then by incorporating a** Branching Strategy in your SCM**.*

---

Now you have set up a source control process for your Power BI dataset. Good job! If you’ve followed the previous two posts, you now:

- Have a **synchronized local & remote repository** for storing files & tracking changes
- Have saved your model metadata there using the **Tabular Editor (TE) folder structure**, to have granular source control on an object-by-object basis
- Are **continuing development in TE on the folder structure**, deploying it to the Power BI service, when committing changes for testing.

There is one easy way that we can **make this process more efficient**. In Step 3, you need to save changes to the folder structure, then deploy the model to the Power BI service if you want to test your changes. This isn’t so convenient, because you need to do a full model refresh after the deployment. Smaller, iterative changes thus are not going to be very pragmatic in this workflow. Further, there are too many manual steps that we can streamline. Thankfully, Tabular Editor 3 has a great solution for this, called** Workspace Mode.**

If you have a **TE3: Business** or **TE3: Enterprise license**, it’s strongly recommended that you continue working in [**Workspace Mode**](https://docs.tabulareditor.com/te3/tutorials/workspace-mode.html) when developing your model. This lets you** simultaneously **connect to the** folder structure** you and a dataset in the **Power BI Service** at the same time. There is thus no need to deploy & refresh your dataset; **changes are saved simultaneously to the repo & QA dataset** for faster testing, *which you can also do straight from Tabular Editor 3* with **Pivot Tables** & **DAX Queries**! This is a tremendous time-saver.

## Getting started with Workspace Mode

![](https://images.data-goblins.blog/2025/12/version-control-pt3-open-folder.png)
### 1. From TE3, connect your database.json & model folder structure

You will be prompted to open the model in Workspace mode.

### 2. Accept the prompt to open the folder in Workspace Mode

![](https://images.data-goblins.blog/2025/12/version-control-pt3-workspace-mode.png)
### 3. Connect to a workspace via XMLA endpoint & select a name for your dataset

<figure class="dg-figure"><img src="https://images.data-goblins.blog/2025/12/version-control-pt3-select-db.png" alt=" Choose a new Database Name or overwrite an existing one "><figcaption>Choose a new Database Name or overwrite an existing one</figcaption></figure>

If you need to overwrite an existing dataset, select the dataset / write the same name, and overwrite it. You will need to refresh all model tables, again - **don’t forget to refresh tables that have scheduled refresh disabled in their properties, i.e. if they are static or helper tables**. You can easily toggle a full refresh from TE3 TOM Explorer.

### 4. Henceforth, when you connect to the folder, you will do so in workspace mode

<figure class="dg-figure"><img src="https://images.data-goblins.blog/2025/12/version-control-pt3-tmuo.png" alt=" .tmuo file specifying workspace mode config - workspace connection string (XMLA) &amp; DB name "><figcaption>.tmuo file specifying workspace mode config - workspace connection string (XMLA) &amp; DB name</figcaption></figure>

A .tmuo file is created specifying the workspace & model name. This file will specify the instructions for which dataset in the Power BI capacity to connect to in Workspace Mode (if you have Premium, or otherwise in Azure AS, SSAS).

---

### The Revised Workflow: Less steps with TE3 & Workspace Mode

<figure class="dg-figure"><img class="dg-plate" src="https://images.data-goblins.blog/2025/12/goblin-blink-good-docs.png" alt=" A simple, sustainable process "><figcaption>A simple, sustainable process</figcaption></figure>

- Open **Tabular Editor**

- Connect to the **Folder in your local repo**

- Make & save changes in **Tabular Editor**

- * Test changes in the **QA data model**:

  - Using data exploration & querying methods from **Tabular Editor 3**

  - and/or using DAX queries from **DAX Studio**

  - and/or using **business reports linked to the QA dataset**

  - and/or [clicky-clicky-draggy-droppy](https://video.twimg.com/tweet_video/EmpIvM-WEAQ64js.mp4) *ad hoc* from **Power BI Desktop or Analyze-in-Excel**

  - With a **custom, automated Build/Test solution using APIs**

- ** Stage and commit changes from **Visual Studio or another GIT tool** (UI or programmatically)

- ** When approved (usually after a tester validates in #6), push changes to your **remote GIT repo**

- ** Push QA dataset changes to **Production workspace**, using your standard** application lifecycle management (ALM) process**:

  - **ALM Toolkit**

  - **Deployment Pipelines**

  - **Programmatically with APIs**

- ** Update Production app(s) where necessary

*Notes:*

** This can be automated with *[*Azure DevOps integration*](https://powerbi.microsoft.com/en-us/blog/deployment-pipelines-azure-devops-extension-multiple-pipelines-working-together-dataflows-ga/)* or custom programmatic solutions, even when i.e. splitting datasets and reports across multiple deployment pipelines*

** Integrate with your own SCM & CI/CD process with i.e. build, test & deployment integration/automation;*
*— this is just an example*

---

<figure class="dg-figure"><img class="dg-plate" src="https://images.data-goblins.blog/2025/12/goblin-blink-bad-adoption.png" alt=" But how can we work collaboratively on the same solution? "><figcaption>But how can we work collaboratively on the same solution?</figcaption></figure>

---

### What is Branching & Why is it Important

One of the powerful aspects of using a source control management (SCM) system is the ability to do what is called **branching**. Normally, when working on i.e. a .pbix from a shared drive, two developers cannot work on it at once without their changes disrupting one another. They would need to work on separate versions of the dataset or report, then manually consolidate changes. This is a painstaking process** prone to human error and wasted time**, even when leveraging external tools like copying/pasting in** Tabular Editor (TE)** or comparing model definitions and manually selecting then pushing changes from one to another in **ALM Toolkit (ALM)**. There is also no documentation of the versions; eventually, changes feel *ad hoc* and chaotic, leading to confusion about who changed what, when.

Branching makes this easier by providing a **framework for a structured process of parallel developments**. Branching is the duplication of an object to allow a developer to work on it without affecting others, but importantly, this duplication and its changes are** tracked as a lineage (a branch) inside in the SCM system**. Changes (visualized as nodes in the below image) in the branch can be automatically merged to consolidate all developments. Conflicts in the merge - for example, if both developers change the same object in different ways - will be raised, blocking the merge until they are resolved.

As one can imagine, using branching to manage version control can provide an elegant way to manage the version control of a Power BI dataset, particularly when tracking changes of individual model objects, thanks to the Tabular Editor folder structure. It’s important to note, though, that there are [many different branching strategies that exist](https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops). With all things SCM, the most important part is adopting a strategy best for your team, then ubiquitously & consistently sticking to it in your development process. The value comes when everyone is aligned with the process and strategy, and adopt it in their way of working.

<figure class="dg-figure"><img src="https://images.data-goblins.blog/2025/12/version-control-pt3-branching-2.png" alt=" Example of how SCM &amp; branching facilitates collaborative development on a Power BI dataset "><figcaption>Example of how SCM &amp; branching facilitates collaborative development on a Power BI dataset</figcaption></figure>

**Example:** Say a defect arises in a report on late orders. At the same time, a high-priority request comes in to incorporate aggregate information about Deliveries. To divide the work, Developers 1 & 2 have created two branches:

- **A bug branch:** Where developer 2 will work on making the changes to fix the bug
- **A feature branch:** Where developer 1 will add the Deliveries table, relationships & measures

Changes can then be merged according to the team’s branching strategy, tested, and eventually deployed to production.

### Collaboratively Working in TE3 with Workspace Mode

Note for **Workspace Mode** users in Tabular Editor 3: A diligent eye might notice an issue: Developer 1 & 2 might have branches on the Repo, but this will have no effect on Tabular Editor or the dataset deployed in the Power BI service*. It is thus a good practice that each developer connecting in Workspace Mode use their **own deployed dataset** to test changes. For other **non-Workspace Mode users should similarly deploy their own specific dataset** to test changes. This can be made smarter using automated CI/CD with Azure DevOps & Power BI integration, also outlined in brief, below:

> *In Azure DevOps, you can create **Automation Pipelines** that leverage the Power BI APIs to perform downstream actions in response to new branches. For example, when a new branch is detected in the Remote Repo, this could trigger:

    1. A re-named copy (branch) of the dataset to be deployed to the Power BI Service

    2. A modification to the .tmuo file in the new branch, pointing to this new dataset for workspace mode

This would ensure that the developer working in the branch can continue to use Workspace Mode to easily test their changes in a deployed branch dataset. Later, **when merging the branch, other pipelines can then handle the dataset appropriately**, deleting it to clean up the QA Workspace. This CI/CD integration between Azure DevOps & Power BI can create extremely effective workflows.

<figure class="dg-figure"><img class="dg-plate" src="https://images.data-goblins.blog/2025/12/version-control-pt3-cicd.png" alt=" A conceptual framework for automated CI/CD using Tabular Editor 3, Azure DevOps &amp; Power BI "><figcaption>A conceptual framework for automated CI/CD using Tabular Editor 3, Azure DevOps &amp; Power BI</figcaption></figure>

---

<figure class="dg-figure"><img class="dg-plate" src="https://images.data-goblins.blog/2025/12/goblin-blink-tools.png" alt="  Tabular Editor 3  +  Azure DevOps  +  Power BI!   A powerful combination of tools can really accelerate productivity &amp; streamline workflows "><figcaption>Tabular Editor 3  +  Azure DevOps  +  Power BI!   A powerful combination of tools can really accelerate productivity &amp; streamline workflows</figcaption></figure>

---

## A quick tutorial on Branching

### 15. Getting started - creating a branch in Visual Studio

> I’ll be brief in my explanations, here, since this is a tutorial focused on Tabular Editor. To get started, you should first read about the different branching strategies, to know when you should create a new branch, from which branch you should base it on, and how you should merge.

First, you need to create a new branch from within Visual Studio, or whatever Git client you are using.

<figure class="dg-figure"><img src="https://images.data-goblins.blog/2025/12/version-control-pt3-search-branches.png" alt=" Select ‘New Branch’ "><figcaption>Select ‘New Branch’</figcaption></figure>

<figure class="dg-figure"><img src="https://images.data-goblins.blog/2025/12/version-control-pt3-create-branch.png" alt=" Give the branch a descriptive name, and base it on the latest branch appropriately "><figcaption>Give the branch a descriptive name, and base it on the latest branch appropriately</figcaption></figure>

### 16. Continue working in the branch

Make the development changes or additions and perform the commits appropriately, using a descriptive message.

### 17. Merge with another branch following your branching strategy

Right-click on the branch in order to merge the changes to another. In the below demo example, the Bugfix changes & Feature changes were merged before merging into the parent ‘main’ branch for testing.

Clicking on each node, you can inspect the changes committed at that specific point in the branch lineage.

<figure class="dg-figure"><img class="dg-plate" src="https://images.data-goblins.blog/2025/12/version-control-pt3-devops-repo.png" alt=" View of the branches and merging from DevOps Repo "><figcaption>View of the branches and merging from DevOps Repo</figcaption></figure>

<figure class="dg-figure"><img src="https://images.data-goblins.blog/2025/12/version-control-pt3-add-deliveries.png" alt=" The  ‘Features_Deliveries’  branch added deliveries information "><figcaption>The  ‘Features_Deliveries’  branch added deliveries information</figcaption></figure>

<figure class="dg-figure"><img src="https://images.data-goblins.blog/2025/12/version-control-pt3-bugfix.png" alt=" The  ‘Bugfix_LateOrders’  branch added and changed DAX &amp; model relationships, unrelated to deliveries "><figcaption>The  ‘Bugfix_LateOrders’  branch added and changed DAX &amp; model relationships, unrelated to deliveries</figcaption></figure>

---

*You’re all set! You’ve now setup SCM for your Power BI dataset and can track changes of each individual object in the model. But don’t forget, for this to bring value…*

---

# SOURCE CONTROL ONLY WORKS WITH A CONSISTENT & SUSTAINABLE PROCESS THAT EVERYONE FOLLOWS

---