Cube Configuration

Extensibility and Linked Cubes

Extensibility is OneStream's key differentiator in cube design — the ability to use different dimensions in different parts of the application without creating entirely separate applications. The OneStream Data Model covers the conceptual overview of both extensibility types, and Scenario Types and Cube Dimensions covers horizontal extensibility (different dimensions per Scenario Type). This guide covers vertical extensibility — different dimensions per business unit via separate linked cubes — and the practical steps to set it up.

Vertical Extensibility

Vertical extensibility uses multiple cubes where each business unit has its own cube with its own dimensions. A parent cube (sometimes called a super cube) sits at the top and consolidates data from the child cubes via the entity hierarchy.

What Varies by Cube

Dimension TypeCan Vary?Notes
EntityYesEach cube has its own Entity dimension with its own base members. The parent cube inherits all entity members from child cubes via relationships.
ScenarioNoShared across all cubes — the Scenario dimension is assigned at the (Default) level and cannot vary by cube.
AccountYesEach cube can have different account structures and levels of detail
FlowYesEach cube can have different flow members
UD1–UD8YesEach cube can have different user-defined dimensions
diagramVertical Extensibility — Dimensions by Cube

Loading diagram...

Each business unit cube defines only the dimensions it needs:
  • North America tracks detailed accounts with cost centers and products
  • EMEA tracks detailed accounts with departments
  • APAC uses summary accounts with sales channels
  • Corporate consolidates at a summary level with a single region dimension
The parent cube does not need to include the detail dimensions from the child cubes. During consolidation, child cube data rolls up to the parent cube's summary dimension level.

When to Use Vertical Extensibility

  • Different business units need different entity hierarchies — each unit has its own organizational structure
  • Different business units need different dimension granularity — one tracks products, another tracks departments, another tracks neither
  • The Data Unit size in a single monolithic cube would be too large because of the combined dimension cardinality
  • Business units have different reporting requirements that cannot be satisfied by horizontal extensibility alone

Setting Up Linked Cubes

Setting up linked cubes involves creating the entity dimensions for each cube, establishing the parent-child relationships between them, and configuring the cube dimension assignments.

Step-by-Step

StepActionDetails
1Create child entity dimensionsEach child cube needs its own Entity dimension containing its base-level entity members (e.g., NA_Entities with members US_Corp, Canada_Corp)
2Create parent entity dimensionThe parent cube needs an Entity dimension with group and consolidated members (e.g., CorpEntities with North_America, EMEA, APAC, Corporate_Total)
3Establish relationshipsIn the parent entity dimension, add the child entity dimension members as children of the appropriate parent members. This links the child cube's entities into the parent cube's hierarchy.
4Create cubes and assign entity dimensionsCreate each cube and assign its Entity dimension on the Cube Dimensions tab under the (Default) Scenario Type
5Assign other dimensions per cubeFor each cube, assign Account, Flow, and UD dimensions on the Cube Dimensions tab for each active Scenario Type
6Verify Cube ReferencesOpen the parent cube's Cube References tab — it should auto-populate with references to the child cubes

Entity Rollup and Consolidation Flow

The key to linked cubes is the entity hierarchy. Child cube entities roll up into parent cube entities through standard consolidation:
diagramEntity Rollup Across Linked Cubes

Loading diagram...

During consolidation, data from child cube entities is translated (if currencies differ) and rolled up to the parent cube entities. The parent cube sees the consolidated totals at its own dimension level. All the standard consolidation mechanics — percent consolidation, share calculation, elimination — work the same as within a single cube.
💡Tip
Test consolidation after setting up linked cubes by loading sample data to a few child entities and running a consolidation. Verify that data appears correctly in the parent cube at the expected consolidation members before building out the full dimension structure.

Cube References Tab

The Cube References tab on the parent cube shows which child cubes roll up into it. This tab auto-populates based on the entity hierarchy relationships — you do not need to manually configure it.
When you establish entity relationships where child cube entity members are children of parent cube entity members, the system automatically recognizes the link between cubes and populates the Cube References tab accordingly.
ℹ️Info
The Cube References tab is read-only and informational. It reflects the current state of entity hierarchy relationships. If you add or remove entity relationships, the Cube References update automatically. The parent cube is sometimes called the super cube because it consolidates data from all child cubes.

What Cube References Show

For each referenced child cube, you can see:
  • The child cube name and its entity dimension
  • The entity members that link the child cube to the parent cube's hierarchy
  • The dimension mappings between child and parent cube dimensions

Intercompany Across Cubes

Intercompany elimination works across linked cubes. When entities in different child cubes have intercompany balances, the elimination occurs at the common parent in the parent cube — just as it would within a single cube.

Key Points

  • IC members are available for all entities in each cube, regardless of which cube the IC partner belongs to
  • The elimination occurs at the first common parent entity in the hierarchy, which may be in the parent cube
  • Both entities must have IsICEntity = True on their entity member properties
💡Tip
Use Conditional Input Rules to restrict which IC members are available for selection in each cube. Without this, users in the North America cube could select IC partners from EMEA or APAC that do not make business sense. Conditional Input Rules keep the IC member list manageable and prevent data entry errors.

Combining Horizontal and Vertical Extensibility

The most flexible cube designs combine both types of extensibility. Horizontal extensibility gives each Scenario Type different dimensions within a cube, while vertical extensibility gives each business unit its own cube with its own dimensions.

Example: Combined Architecture

Consider a corporate group where:
  • Corporate parent uses summary accounts for all scenarios
  • North America uses detailed accounts for Budget but summary accounts for Actual
  • EMEA uses detailed accounts for both Actual and Budget, with department breakdowns only in Budget
diagramCombined Horizontal and Vertical Extensibility

Loading diagram...

In this design:
  • Vertical extensibility handles the different entity structures and dimension needs per business unit
  • Horizontal extensibility handles the different dimension needs per financial process within each business unit
  • The Corporate cube consolidates everything at the summary level, regardless of the detail available in each child cube

Configuration Summary

CubeScenario TypeAccountUD1UD2
CorporateActualSummaryAccountsRegionRootUD2Dim
CorporateBudgetSummaryAccountsRegionRootUD2Dim
NAActualSummaryAccountsRegionRootUD2Dim
NABudgetDetailAccountsRegionCostCenter
EMEAActualDetailAccountsRegionRootUD2Dim
EMEABudgetDetailAccountsRegionDepartment
💡Tip
Always stub out unused dimensions with the Root dimension (e.g., RootUD2Dim) rather than leaving them at (UseDefault). This applies in linked cubes just as it does in single cubes — it preserves future flexibility to add dimensions to specific Scenario Types without affecting others.

Related Content