Version Control & Branching

Product Architecture is not a One-person Task

To create and manage a product architecture you need to collaborate with other colleagues and functions.

Most large and mid-size organizations also have a global footprint and encourage flexible work environments. You want to work at the office, during business trips, or from home. The days when collaboration and data conflicts could be managed by shouting across the office are long gone.

Modern demands on cloud-based enterprise software such as PALMA® are high. When it comes to version control, they include:

  • Clear and transparent change management. What was changed, by who and when?
  • Version control, with the ability to roll back to or inspect previous versions
  • Guarantees that users always have access to the system
  • Secure data integrity while maximizing the productivity and freedom of teams
  • Sandbox mode so radical changes can be explored before they’re shared with other users and systems
  • Control over who can access or edit which version or versions
  • Clear history for a good overview of data development over time.

Different Levels of Version Control

Revision Control

The most common way of managing different versions of a file or a document is revision control. Changes are identified by a code which represents the document’s revision number for example 1.0, 1.1, 1.2 and so on. Each version contains metadata such as time stamp and the person who made the change, but without strict discipline there is a risk that two users start editing the same version, which then creates confusion about which version is the latest.

Check Out, Check In

To avoid confusion with simple revision control, a check-out/check-in principle can be applied. It requires a user to check out a file or a database before going into edit mode. This locks the file for all other users until the file is checked in again, and effectively prevents conflicts, since only one user at a time can edit data.

The downside is that this reduces productivity and makes collaboration more difficult. Parallel work is prohibited and users that forget to check things back in cause roadblocks, basically stopping collaboration.

Real-time Collaborative

Another type of version control is real-time collaborative editing. This means different users can edit simultaneously and changes are merged pretty much instantaneously.

A big technical challenge to this principle is that it requires fast, low-latency internet connections. With only slight latency, edits are not merged immediately, and users find themselves working on different version of the data. This creates uncertainty and can be confusing if a lot of data is changing in real-time. This can also discourage users to make anything but small incremental changes, since every action they take impacts master data.


Branching is an advanced version control principle that allows users to work in parallel, in branches that are merged back to the master work branch when appropriate. This gives confidence, autonomy and the ability to try out different solutions while still having control over the master data.

Git is a well-known example from the software industry of this latest model and has been in used for many years in the cloud solution GitHub, used by individual developers as well as large multinational companies.

PALMA is a solution for Product Architecture Lifecycle management. As a product architecture is complex, with many contributors and numerous interdependencies that continuously develops over time, version management through branching is the only solution that can meet advanced company requirements.

How Does Branching Work?

PALMA® is a cloud-based solution that gives all users access to a central database through a web browser.

Data is edited in real time and changes are stored to the database. The main version of the data is called the master branch. Changes are stored sequentially and form a timeline of changes known as change-sets. Users however are not working directly on the master branch. When a user enters edit mode, a personal branch or workspace is created. A user can then make changes, including creative experiments and mistakes, and correct them without them being immediately reflected on the master branch. It is not until the user decides to commit changes that they become visible to other users, as a new change set on the master branch.

Branching opens up for advanced use cases.

How to Use Branching?

An example of an advanced use case is when a team wants to make a radical change to the module system.

The team can branch off and commit to a design branch instead of the master branch. Team members can collaborate and decide, later on, whether to merge their design branch with the master or terminate it. Branching enables teams to work in an agile and concurrent way, while still having full control over master data. In an enterprise context, with integrations to PLM, CPQ and ERP solutions, this is critical to avoid confusion in and between systems.

Branching also means that teams can control releases of the existing module system while working on future releases.

Master Branch with Personal Workspace

Overview of Module System Branching Tree

Version Control in PALMA

Thanks to branching, PALMA meets challenging requirements for version control:

  • Transparency as to who changed what – and not just on a single timeline, but on multiple branches of the timeline. Each change-set can be opened and explored to see changes.
  • Easy rollback to previous versions or change-sets. If there are uncertainties about a change, you can roll back by opening up a new design branch from a previous state. You can also decide later whether it should be the master branch moving forward.
  • Users have continuous system access. No check-outs or check-ins.
  • Master versions protected by appointing a merge agent that has the rights to authorize a merge to the master branch.
  • Sandbox mode to test a hypothesis in a controlled manner by branching off on a design branch and deciding later if the branch should be merged to the master.
  • Branch teams able to control who has what access to which version of the data.
  • History exploration by opening a branch and moving through the timeline. The historical states of a selected tool are dynamically updated in PALMA.
  • Change history can be examined by a journal, a change log, for each item or change-set.


Branching enables effective collaboration and version control.

Since creating and managing product architecture is not a one-person task, the branch manager in PALMA® facilitates master data management and supports your different ways of working. Get in touch if you’re curious to find out more about this world-leading solution for agile product management.

Gustav Grenås

Product Manager

T: +46 8 456 35 00