This is an article to introduce core concepts behind and implementation of branching via a generic workflow. It is not intended to cover all other possibilities for branching: see other relevant articles.
Branching is an OrgVue feature designed to be a ‘holding ground’ for changes. It is a mechanism by which one can view a dataset, make changes to a dataset and save these changes without ever changing the dataset underneath.
It is then possible to report upon the difference between these changes at a high level, such as the difference in number of records, all the way down to the row by row changes, such as the individual salary changes of a person, using the Changes Report.
Using branching, it is possible to model organisational changes, where a branch typically represents either a given scenario or a given organisational segment.
- One can branch from an organisational people dataset to create the ‘holding ground’ for changes.
- Changes to the organisation are made in one or more branches, and reports can then be run on the changes between the branch (the updated organisation) and trunk (the current organisation) and on the branch independently.
- This facilitates effective side by side comparison of organisation models; showing us the impact of the changes we make, as we make them, without actually being committed to making them.
- The Changes Report allows for the trunk to have a dynamic relationship with the branching structure i.e. potentially both the trunk and branch content may alter
- To maintain the validity of the approach overall, there is an assumption that pushback from branch to trunk never occurs without first validating impact via Changes Report
My aim is to have a baseline data set from which I create branches in order for different teams to do redesign on specific functions. I only want those teams to be able to edit the particular function they are assigned, so I want their branch either to only contain part of the baseline data-set or have sufficient limits that they cannot reorganise functions beyond their own.
Proposed Solution to Scenario
We would recommend the best way of doing this is filtering to specific areas before you create your branches, and then tagging those branches as a way of allocating different permissions to different groups. This is straightforward to implement and also to keep track on who has access to what.
In terms of security, we would propose:
|Baseline||view:team1,team2||Can be seen by everyone with the role “team1” or “team2”|
|To Be||update:team1,team2; private||Hidden – but can be edited by everyone with the role “team1” or “team2”|
|To Be (branch 1)||update:team1||Can be updated by everyone with the role “team1”|
|To Be (branch 2)||update:team2||Can be updated by everyone with the role “team2”|
Implementing Dataset Branching
In the section below, we explore scenario modelling using branching for multiple workstreams. Note this implementation is not intended to directly map to the example scenario above.
1. We need version control to let workstreams update only their part of the scenario – and for the central team to reintegrate them easily
The conceptual model is as follows:
- Read only
- Safeguards The Baseline
- Starting point = a copy of The Baseline
- Created by central team
- Whole is visible only to central team
Branches of the Scenario
- Can be updated by the workstreams (branches)
- Changes tracked vs The Scenario
- Pushed back to The Scenario when workstream is satisfied to create The Compiled Scenario
The Compiled Scenario
- Generated automatically from all the changes pushed back from the workstreams
2. Set up Users in the User Permissions table with the roles that will be used for their source dataset and branches
3. Set up the Baseline dataset and the Scenario dataset with tags to be viewed or updated by users who have ‘branches’ roles
Note that when setting Apply Tag (see article here) a different permission type must be set on a different line, but once saved each permission type will appear on the same line separated by ; i.e. the Scenario 1 example above must be configured as
to display as
4. Set up other branches, saving each one and tagging it for the relevant users to update
5. Note that the user sees only the Baseline and their branch because the Scenario dataset is marked ‘private’
6. While the user with role ‘branch1’ can update Branch 1 and see changes vs the whole Scenario 1 dataset
7. It is possible to see the net effects of changes from various dimensions using Changes Report (Dashboard)
8. Once changes have been agreed, the user with role ‘branch1’ can push their changes back to the whole Scenario 1 dataset
Contributors: Tom Simpkins and El No