---
url: /technical/managing-dimension-manually.md
description: >-
  Clicking Manage on an existing dimension within the model page will open the
  Dimension Manager for the selected dimension.
---

# Managing a Dimension Manually

Clicking **Manage** on an existing dimension within the model page will open the Dimension Manager for the selected dimension. It's a single page exposing everything needed to work with the Dimension manually - Hierarchies, Aliases, and quick navigation to other Dimensions in the Model - and it opens with the `Default` Hierarchy loaded automatically, since that's the one edited most often.

![The Dimension Editor, annotated to show the hierarchy list, alias list, other dimensions, the tab-indented hierarchy text editor, and the Download Hierarchy, Find Duplicates and Audit Dimension actions](/dimension-editor-annotated.png)

There's no separate page listing every leaf Element in a Dimension flat - the editor is Hierarchy-centric, so the closest equivalent is opening a Hierarchy that happens to contain all of them (typically a dedicated flat Hierarchy created for that purpose, like `All Accounts`), or using the Audit tool below.

## Editing a hierarchy

When editing a hierarchy MODLR provides a text area and interprets tab depth to define the tree of elements. This works well when copying and pasting hierarchies from MS Excel workbooks - paste a tab-indented range straight in and it becomes the Hierarchy structure, with no drag-and-drop required:

```
All Departments
    Finance
    Marketing
    Sales
        Sales - Online
        Sales - Retail
    Operations
```

![Editing a hierarchy in the text-based hierarchy editor, with tab-indented elements defining the parent-child structure](/dimension-editor-hierarchy-text-editor.png)

Saving a Hierarchy creates any new Elements, links them according to the indentation, and removes from *this Hierarchy* any Element no longer present in the text - removing an Element from a Hierarchy doesn't remove it from the Dimension itself; see [Auditing a dimension](#auditing-a-dimension) below for what happens to it instead.

Additional Hierarchies can be created alongside `Default` from the same editor, each with its own tab-indented structure - the same leaf Elements can appear in any number of Hierarchies, which is the mechanism behind the multiple-roll-up pattern described in [Designing a Dimension](/technical/designing-a-dimension#four-core-decisions).

Two modifiers can be appended to an Element name in the text editor:

* **`[-1]`** sets the Element's consolidation weight to -1 for this placement, subtracting it from its parent instead of adding it - useful for a variance Hierarchy like:
  ```
  Variance Act vs Bud
      Actual
      Budget[-1]
  ```
  The weight is part of the *placement*, not the Element itself - the same Element can carry `[-1]` in one Hierarchy and the default weight of `1` in another.
* **`[s]`** creates the Element as a **string** Element rather than the default **numeric** one - relevant on a Measures Dimension, where a `Comment` or `Description` measure needs to hold text rather than a number:
  ```
  Amount
  Comment[s]
  Description[s]
  ```
  Once created, an Element's type is fixed and shared across every Hierarchy that contains it.

## Aliases

Aliases - alternative names for Elements - are managed alongside Hierarchies in the same editor, and a Dimension can carry any number of them.

![The alias list in the Dimension editor, showing several configured aliases and the action to mark one as default](/dimension-editor-alias-list.png)

One Alias can be marked **default**. The default Alias is what new Workviews built from any Cube using this Dimension display automatically, in place of the principal Element name - so an Account Dimension using codes as principal names (`6-10010`, `6-10020`) with a `Code - Name` Alias (`6-10010 - Services Revenue`) set as default means every new Workview reads correctly without a modeller having to remember to switch the display Alias. This only affects *new* Workviews - existing ones keep whatever Alias they were already configured with. See [Naming elements from a source system](/technical/designing-a-dimension#naming-elements-from-a-source-system) for the pattern this is designed to support.

Editing Alias values is done Element by Element through this editor, which is fine for small Dimensions but doesn't scale - for anything with more than a handful of Elements, populate Aliases from a [Process](/technical/creating-dimension-via-process) instead, using `alias.set`.

## Finding duplicates within a hierarchy

The dimension page's **Find Duplicates** action checks the currently open Hierarchy for any Element that appears in it more than once.

![The Find Duplicates modal listing elements that appear more than once in the currently open hierarchy, along with the parent each duplicate sits under](/dimension-editor-find-duplicates.png)

Most duplicates inside a single Hierarchy are unintentional - an Element placed under two different parents by mistake while editing manually, a scripted Process whose logic missed an edge case, or two Hierarchies merged from overlapping sources. There are legitimate reasons for an Element to appear twice (a cost that genuinely contributes to two different totals), but they're rare enough that Find Duplicates is best treated as a diagnostic for catching mistakes, not something exercised routinely. When a duplicate is unintended, the fix is usually to edit the Hierarchy and remove the redundant placement.

## Exporting a hierarchy to CSV

Each Hierarchy in the editor has a download action that exports it as a CSV file:

| Field | Meaning |
| --- | --- |
| `parent` | The parent Element name. |
| `child` | The child Element name. |
| `weight` | The consolidation weight of the child under the parent - `1`, or `-1` for subtraction. |
| `type` | The Element type (`N` for numeric, `S` for string). |
| `position` | The position of the child under the parent. |

![The per-hierarchy CSV export action in the dimension editor](/dimension-editor-hierarchy-csv-export.png)

This is useful for sharing a Hierarchy with a stakeholder outside the platform, diffing two versions of a Hierarchy, backing one up before a major change, or feeding it into another tool or another MODLR Model. It's also the same shape that Hierarchy-building Processes typically read from when populating Dimensions automatically.

## Auditing a dimension

Removing an element from a hierarchy doesn't remove it from the dimension - it becomes an **orphaned element**: still present in the dimension's element list, with any data against it untouched, but no longer reachable through any roll-up. The Dimension Manager's **Audit Dimension** action finds these orphans and can remove them from the dimension.

![The Audit Dimension modal, annotated to show the list of orphaned elements and the Remove Orphans action](/dimension-editor-audit.png)

::: warning
Removing an orphan is not the same as removing its data. The element leaves the dimension's list immediately, but its data stays in cube storage until the server is next restarted - so an orphan removed by mistake can be fully undone by re-adding it to a hierarchy before that restart, but the data is gone for good the moment the server restarts. See [How to remove unused data from a cube](/technical/how-to-remove-data-from-a-cube) for the full workflow.
:::