> For the complete documentation index, see [llms.txt](https://help.modelreef.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.modelreef.io/help/building-your-model/branch-hierarchy-rules.md).

# Branch Hierarchy Rules

This article explains the rules of the branch hierarchy in Model Reef and how to apply them when designing your model structure.

You will learn:

* How the branch tree is organised.
* What each branch can contain.
* How parent and child branches interact.
* How to safely add, move and disable branches.

Branches are the main way you represent entities, divisions, locations and projects inside a model.

{% stepper %}
{% step %}

### The branch tree

Every model has a branch tree:

* A single root branch that represents the consolidated total for the model.
* Zero or more child branches under the root.
* Child branches can themselves have children, giving you multiple levels of detail.

Examples:

* Company
  * Entity A
  * Entity B
* Group
  * Country 1
    * Division 1A
    * Division 1B
  * Country 2

There is no hard limit on depth, but keep the tree understandable for humans.
{% endstep %}

{% step %}

### What branches contain

Each branch can contain:

* Variables of any type (Revenue, COGS, Opex, Staff, Asset, Liability, Equity, Tax, Dividend, Modifier).
* Links to Data Library entries via those variables.
* Notes, attachments and tags on the variables.
* Branch level reports and dashboards (P\&L, Balance Sheet, Cashflow, Cash Waterfall) derived from its variables and those of its children.

Branches do not contain separate scenarios. Each scenario is a separate model that has its own branch tree.
{% endstep %}

{% step %}

### Branch contribution rules

Contribution rules are simple:

* A variable contributes to the branch it lives in.
* Parent branches show the sum of their own variables plus all variables from child branches (and their children, recursively).
* The root branch shows the consolidated results for the entire model.

This holds across:

* P\&L.
* Balance Sheet.
* Cashflow Statement.
* Cashflow Waterfall.
* Dashboards and custom reports.

There is no double counting as long as each variable lives in exactly one branch.
{% endstep %}

{% step %}

### Enabling and disabling branches

You can enable or disable a branch:

* When a branch is enabled, its variables contribute to parent and root branch results.
* When a branch is disabled, its variables are ignored in aggregations, but they are not deleted.

Disabling is useful for:

* Testing the impact of a new division or project before including it in the main view.
* Comparing a version of the business with and without a specific unit.
* Temporarily hiding an entity that is being restructured or wound down.

Children of a disabled branch are also excluded from consolidation unless they are moved elsewhere in the tree.
{% endstep %}

{% step %}

### Moving and reparenting branches

You can change the tree structure at any time by:

* Dragging a branch to a new parent.
* Promoting a child branch to a higher level.
* Demoting a branch under a new parent.

When you move a branch:

* All its child branches move with it.
* All variables move with the branch that contains them.
* Consolidated results update automatically based on the new structure.

This lets you restructure entities, divisions and projects without rebuilding variables.
{% endstep %}

{% step %}

### Duplicating branches

You can duplicate a branch to reuse its structure and variables, for example:

* Clone a store or clinic structure to roll out to a new location.
* Duplicate a project template branch for a new project.
* Create a draft version of a division branch for structural changes.

When you duplicate a branch:

* All child branches are duplicated.
* All variables in the branch tree are duplicated.
* Data Library entries are referenced, not duplicated, unless you choose to create separate series.

The new branch can then be customised independently.
{% endstep %}

{% step %}

### Permissions and branch hierarchy

If you use branch level permissions:

* Access granted at a branch cascades down to its children.
* Access does not flow upwards to parent branches.
* A user with access to a branch can see and edit variables in that branch and all its descendants, but not in ancestors or other branches.

Design your hierarchy so that:

* Sensitive areas can be isolated under specific branches.
* Teams can work safely in their part of the tree without seeing everything.
  {% endstep %}
  {% endstepper %}

## Related articles

* [Inventory Purchases & Reorders](/use-cases/ecommerce-and-d2c-brands/inventory-purchases-and-reorders.md)
* [Build a Staffing Cost Model](/how-tos/operations-and-unit-economics/build-a-staffing-cost-model.md)
* [Folder Structure](/help/workspace-and-organisation/folder-structure.md)
* [Editing Units](/syntax/how-input-fields-work/editing-units.md)