# Other dimensions (/docs/indicator-apps/dimensions/other-dimensions) A **dimension** is a way to break a metric down so you can track it in more detail. Besides time, you can give an indicator dimensions like **Region** or **Site**. Without a dimension, an indicator holds a single value each period. With one, it holds one value each period for each part of the breakdown, so instead of a single company-wide total you collect a value per region. ## Members and levels [#members-and-levels] A dimension is made of **members** and, optionally, **levels**. * A **member** is one entry in the breakdown, for example "North" or "South". * A **level** groups members into a hierarchy, with each member sitting under a parent one level up. A hierarchy can be **up to five levels deep**. For an organisation you might build a Location dimension like this: ``` Country Germany Switzerland Region South North Central Site Munich Stuttgart Berlin Zurich ``` Here **Country** is the top level with two members (Germany, Switzerland), **Region** sits under it, and **Site** is the bottom level where you actually enter data. You build the dimension by adding its levels top to bottom, then the named members within each. Collecting at the bottom (per site) lets Ovidens roll the figures up to the top (per country) automatically. ## Assign a dimension to an indicator [#assign-a-dimension-to-an-indicator] When you assign a dimension to an indicator, that indicator becomes **collected per member**. In practice this means data entry asks for a value for each member rather than a single value. A Region dimension on your energy indicator, for example, means you enter energy use for North, South, and so on, each period. An indicator can have more than one dimension, in which case you collect a value for each combination, for example each region in each period. ### One level, and every dimension named [#one-level-and-every-dimension-named] An assignment also picks **the level the indicator collects at**. Values are entered at that level and nowhere else: totals for the levels above it are calculated from what you entered, never stored a second time, which is what keeps a country total and the sites under it from drifting apart. Two things follow, and the platform enforces both rather than storing a value nothing can read: * A value must name a member **at the collection level**. A member above or below it is refused, with a message saying so. * A value must name a member **for every dimension** the indicator is assigned. There is no "unspecified" cell on a dimensioned indicator. The data-entry grid shows exactly those cells, so what you can see is what you can fill in. Two things follow from that: * **A level with no members yet shows no columns.** If you assign a `Country > Site` dimension while only countries exist, pick Country as the collection level - or add the sites. The grid says which of the two it is rather than showing columns nothing can be entered into. * **A member above the collection level is not a cell.** A country with no sites under it does not get a column on a site-level indicator. Collect at country level, or add a site. If you change the collection level after values have been entered, the values already stored stay where they are and stop being read. The **Stranded data** list on the Pipeline tab names them, and the remedy is to bring them back onto the grid: set the collection level back to the one they were entered at, and they are cells again. Once they are, you can clear them the way you correct any other value - empty the cell and save - and then change the level. A cell the grid does not show cannot be cleared from the grid, which is exactly what makes it stranded. ## The reporting-unit dimension [#the-reporting-unit-dimension] If you run [rounds](../collection-rounds.mdx), one of an app's dimensions is its **reporting-unit dimension**: the one whose members are the units you ask named people to answer for. There is exactly one per app, and every collection round of that app asks along it - so everybody's responsibility is expressed in one vocabulary. Set it in the editor under **Structure -> Dimensions**: open the dimension and turn on **Reporting-unit dimension**. Turning it on for another dimension moves it; a dimension list never shows two. Two rules follow: * **The app has to be published for a round to leave draft.** Collection runs against the published structure, so set the dimension, publish, then open the round. * **Once a round is running or finished, the dimension can no longer be moved** - because its answers and review decisions name members of it. Setting it back to the dimension the published structure carries stays allowed, and that is the repair if a draft has drifted away from it. A round still in draft holds nothing. To collect along a different axis, reset those rounds' review decisions and return them to draft, or use a separate app. * **Deleting the dimension is refused sooner than that**: while the app holds ANY round, a draft one included, because a draft round's people are already assigned to its members. The two rules have different starting points on purpose - a round leaving draft is what pins the CHOICE, having a round at all is what protects the DIMENSION. ## Why hierarchies stay shallow [#why-hierarchies-stay-shallow] The five-level cap is deliberate. A hierarchy of Country, Region, and Site is easy to read and quick to enter; going deeper multiplies the cells a collector has to fill and rarely adds insight. Keep yours shallow and focused on the breakdowns you actually report on.