> 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/workspace-and-organisation/folder-structure.md).

# Folder Structure

You will learn:

* How folders work and what they contain.
* Common patterns for organising folders.
* Naming conventions that help models stay discoverable.

{% hint style="info" %}
Folders are for navigation and organisation only. They do not change how models are calculated.
{% endhint %}

{% stepper %}
{% step %}

### How folders work

Inside a workspace you can create folders that contain:

* Models.
* Scenario or version models.
* Model templates.
* Sub folders.

Folders:

* Can be nested to any depth.
* Can be renamed or moved without affecting model logic.
* Do not change permissions on the models themselves.

Folder structure is a visual and organisational layer, not a security layer.
{% endstep %}

{% step %}

### Common folder patterns

Here are some patterns that work well in practice.

#### Client based structure

For advisory and accounting firms:

* One top level folder per client.
* Inside each client folder, separate folders for:
  * `Forecasts`
  * `Valuations`
  * `Transactions`
  * `Archives`

This keeps all of a client's models in one place.

#### Entity or division based structure

For groups with multiple operating units:

* One folder per legal entity or division.
* Shared templates at the top level.
* Consolidated group models in a dedicated `Group` folder.

#### Year or planning cycle based structure

For internal FP and A teams:

* Top level folders per financial year: `FY2024`, `FY2025` and so on.
* Within each year, folders for:
  * `Budget`
  * `Reforecast`
  * `Board packs`

This makes it easy to move from one planning cycle to the next.
{% endstep %}

{% step %}

### Naming conventions for folders and models

To keep the workspace clean:

* Use clear, descriptive folder names such as `Client - Name` or `Entity - Region`.
* For models, include:
  * Entity or project name.
  * Purpose (Forecast, Valuation, Transaction).
  * Version or scenario indicator if relevant.

Examples:

* `Client - Acme Co`
* `Acme Co - Group Forecast FY2026 - Base`
* `Project Orion - LBO Model - Upside`

Consistent naming reduces errors when opening or sharing models.
{% endstep %}

{% step %}

### Moving models and folders

You can move models between folders without affecting:

* Their internal branch structures.
* Variables, drivers or assumptions.
* Permissions assigned at model level.

Moving a model is simply a reorganisation step at workspace level.
{% endstep %}

{% step %}

### Folders and permissions

Folders do not provide security by themselves. Access is controlled by:

* Model level roles.
* Branch level permissions inside each model.

A user may be able to see a folder but not open certain models inside it if they have not been granted access.
{% endstep %}
{% endstepper %}

## Related articles

* [Campus/Program Consolidation](/use-cases/education-providers-private-vocational/campus-program-consolidation.md)
* [Valuation](/how-tos/valuation.md)
* [Units & Bounds](/help/drivers-variables-and-timing/units-and-bounds.md)
* [Linking Drivers to Variables](/syntax/drivers-syntax/linking-drivers-to-variables.md)