Skip to content

Design a Dimension Hierarchy

~30 minutes · a dimension, an alternate hierarchy, used downstream

Dimensions are the hierarchies everything else in PlaidCloud builds on — allocations target them, dashboards slice by them, reports roll up through them. Yet most guides reference dimensions without ever teaching you to build one. This tutorial closes that gap: you’ll create a cost center dimension, give it a second way to roll up, populate it from a table, and hand it to a downstream consumer.

A cost center dimension with a main hierarchy that groups centers by department, plus an alternate hierarchy that re-groups the same centers by region. Then you’ll load it from a source table and point an allocation at it.

CompanySalesOperationsCC-100CC-200CC-300CC-400EastWestMainBy Region
The main hierarchy groups cost centers by department; the alternate re-rolls the same four leaves by region. Same leaves, different parents.
  • A PlaidCloud workspace (start a free trial if you don’t have one)
  • A project to work in (create one from the Projects tab if needed)
  • Familiarity with Concepts — workspace, project, workflow, dimension
  • Optionally, a source table with cost center structure for the load in Step 4 (you can also build the tree by hand)

New to the idea? Read Getting Started with Dimensions first. It explains when a dimension earns its keep and how the main and alternate hierarchies relate — the vocabulary this tutorial assumes.

Dimensions live in the Dimensions tab within each project.

  1. Open your project and switch to the Dimensions tab.
  2. From the New button in the toolbar, choose New Dimension.
  3. Enter a name (e.g., Cost Centers), a directory for folder-style organization, and a descriptive memo.
  4. Click Create. The dimension is ready immediately.

You now have an empty dimension — a shell with a main hierarchy and nothing in it yet. The next step gives it structure.

Every dimension has one main hierarchy: the canonical, single-truth tree where every leaf member is registered exactly once. Build the department structure here.

  1. With the dimension open, select the root and click Add Member on the hierarchy toolbar to create the top-level parents — Sales and Operations.

  2. Select a department and use Add Member again to add the leaf cost centers that roll up to it:

    Parent Leaf members
    Sales CC-100, CC-200
    Operations CC-300, CC-400
  3. The hierarchy toolbar also moves members up and down and re-parents them directly, so you can fix any member you place wrong.

Every leaf must live in the main hierarchy. Anything anywhere in the dimension is first a member of the main tree — the only open question is where it sits. Alternate hierarchies (next step) reuse these leaves; they never introduce new ones.

For large trees, arranging members by hand gets tedious. The Dimension Sort workflow step sorts programmatically — a real time saver after a load or a big restructure.

An alternate hierarchy is a different view of the same leaves. It can pick a subset, group them differently, or use an entirely different roll-up. Here you’ll re-group the four cost centers by region instead of by department.

  1. Add a new alternate hierarchy to the dimension and name it By Region.

  2. In the new hierarchy, use Add Member to create two parents — East and West — then add the existing leaves under them:

    Region parent Leaf members
    East CC-100, CC-300
    West CC-200, CC-400

The leaves are the same members from the main hierarchy — you’re re-parenting them for this view, not duplicating them. Members in the main hierarchy carry attribute labels showing which alternate hierarchies they also belong to, so you can see at a glance that CC-100 is both a Sales center and an East center.

Two common alternate patterns. A subset view pulls a focused set of leaves into a tree for one report or allocation; it inherits member changes from the main. A different roll-up keeps every leaf but re-groups them, as By Region does here. See Using Dimensions (Hierarchies) for both.

Building a few nodes by hand is fine for a tutorial. In practice you populate a dimension from a source table via a workflow, so it refreshes as the source changes. PlaidCloud reads two data shapes:

Format Shape Best for
Parent-Child Two columns — one parent, one child — one edge per row Arbitrarily deep, irregular hierarchies
Levels One column per level, one full path per row Regular hierarchies with predictable depth
  1. Switch to the Workflows tab and create a workflow (e.g., Load Cost Centers).
  2. Add a Dimension Load step.
  3. Point it at your source table, choose Parent-Child or Levels, and map the columns that carry the structure.
  4. A load can carry more than structure — values, aliases, and properties can ride along in the same step. Map those columns too if your source has them.
  5. Run the step, then reopen the Dimensions tab to confirm the tree matches your source.

A load builds structure; it doesn’t reset the dimension. To wipe a dimension back to empty before reloading — clearing structure, values, aliases, properties, and alternate hierarchies — use Dimension Clear first. See Loading and Unloading Dimensions for the round trip, including exporting the hierarchy back to a flat table for reporting.

A hierarchy can be more than a tree of names. Each node can carry properties (a cost center’s currency, its owning business unit), aliases, and values. Toggle Properties on the hierarchy toolbar to show a column per property, and add one with New Property.

You can also compute values directly in the hierarchy. Aggregations pull summed, counted, min, or max values from a table into each node, and Expressions calculate from those aggregations using math operators, conditionals, and functions like Column(...), Leafcount(), and Parentvalue(...). See Dimension Functions for Expressions and Aggregations for the full set.

The payoff: define the tree once, reference it everywhere. Your dimension is now a target for the rest of PlaidCloud.

  • Allocations target a dimension to spread a cost pool across its leaves — the natural next step below.
  • Reports and dashboards slice and drill through the hierarchy, using the main tree for one roll-up and By Region for another, from the same underlying leaves.
  • Dimension-mapped columns in a Data Editor or in another dimension’s Select (Dimension) property let users pick members from your tree through a member picker.

To feed an allocation, keep the leaf member names in your dimension identical to the keys in your driver and source data — a mismatch in spacing or casing means a leaf receives nothing. That contract is exactly what the allocation tutorial builds on next.