OneStream

The OneStream Data Model

Before writing a single line of code, you need to understand how OneStream stores data. The platform is built around a multidimensional cube — a structure that will feel familiar if you have worked with OLAP tools like Essbase or Analysis Services, and unfamiliar if your background is purely relational databases. This guide explains the data model from the ground up.

The Multidimensional Cube

A cube is a data structure where every cell is identified by the intersection of multiple dimensions. Think of a spreadsheet: rows might be accounts and columns might be months. That is a two-dimensional slice. Now imagine adding a third axis for Entity (which company), a fourth for Scenario (Actual vs. Budget), a fifth for Department, and so on. The result is a cube with 10 or more axes, where each unique combination of dimension members identifies exactly one data cell.
diagramCube as Dimensional Intersection

Loading diagram...

In this example, the cell at the intersection of Entity = US_Corp, Account = Revenue, Time = 2026M3, Scenario = Budget, Flow = Ending, and UD1 = Sales Dept holds the value $1,250,000. Change any one of those coordinates and you are looking at a different cell.
ℹ️Info
OneStream stores cube data sparsely — only cells that contain data (or have been calculated) take up storage. You do not need to worry about the theoretical size of the cube (which can be enormous). The engine is designed to handle millions of populated cells efficiently.

Cube Design

A single OneStream application can contain multiple cubes, each with its own dimension structure. The choice of how many cubes to create — and how they relate to each other — is one of the most consequential architectural decisions you will make. It affects Data Unit size, calculation performance, extensibility, and how easily the application can grow over time.
The key trade-off: fewer cubes are simpler to build and maintain, but more cubes with targeted dimensions give you better performance and flexibility through extensibility.

Cube Design Patterns

OneStream applications typically follow one of these cube design patterns:
PatternDescriptionBest For
Monolithic CubeSingle cube with all scenarios and entities. No extensibility.Small or simple applications, lift-and-shift migrations
Linked Cubes (Super Cube)Parent cube with detail cubes rolling up via the Entity dimension. Most common design.Most implementations — best use of extensibility
Paired CubesSplit or shared entities across cubes for special consolidation needs.Complex org structures with shared or split entities
Specialty CubesLimited-purpose cubes for admin data, drivers, overrides, or process control.Separating admin/driver data with simple security
Exclusive CubesSeparate cubes moving data via Business Rules or Data Management, not cube references.Fully independent business units with separate workflows
Monolithic Cube — The simplest design. Everything lives in one cube, and all Scenario Types share the same dimensions. This works for small applications and is common for lift-and-shift migrations where the goal is to get running quickly. The downside is that you cannot use extensibility, so every scenario pays the cost of the largest dimension. This design is rarely recommended for applications of any size.
Linked Cubes (Super Cube) — The most common production design. A parent cube sits at the top with detail cubes rolling up to it. Each detail cube can have its own dimensions and level of detail, while the parent cube consolidates at a higher level. This pattern makes the best use of extensibility and provides the most flexibility for future growth.
diagramLinked Cubes Architecture

Loading diagram...

Paired Cubes — Used when entities need to exist in multiple cubes (split entities) or when users load to the same entity from different cubes (shared entities). Since dimension members can only belong to one cube, paired cubes use a common Entity dimension with all base members assigned to every cube, plus a second hierarchy dimension per cube. This is the most complex pattern and is reserved for situations that specifically require it.
Specialty Cubes — Monolithic cubes that serve a narrow purpose: holding driver assumptions, override tables, equity control data, or process control configurations. The benefit is simple security — you can easily separate administrative data from the main financial cubes.
Exclusive Cubes — Completely independent cubes that do not reference each other directly. Data moves between them via Business Rules or Data Management jobs. This suits organizations where business units have fully separate workflows, dimensions, and security requirements.
Having many cubes will not slow the application. The gains in performance from smaller Data Units typically outweigh the additional maintenance.

Extensible Dimensionality

Extensibility is the key differentiator in cube design. It allows different parts of the application to use different dimensions (or different levels of detail within the same dimension) without creating entirely separate applications.
Horizontal Extensibility — Different dimensions per Scenario Type within the same cube. For example, Actual might use SummaryAccounts while Budget uses DetailAccounts with additional driver accounts. The Entity and Scenario dimensions must be shared across all Scenario Types, but Account, Flow, and UD dimensions can vary.
ActualBudgetForecast_Working / Forecast_MX
EntityLegalEntityLegalEntityLegalEntity
AccountSummaryAccountsDetailAccountsDetailAccounts
UD1ProductFamilyProductTypeProduct
UD2—CostCenter—
UD3—DepartmentDepartment
This extensibility happens within a single cube — no additional cubes are needed.
Vertical Extensibility — Different dimensions per business unit via separate cubes with a master/parent cube. Each business unit cube has its own Entity dimension that is inherited by the parent cube. Account, Flow, and UD dimensions can also vary across cubes, giving each business unit the reporting detail it needs while still consolidating into a single corporate view.
diagramVertical Extensibility — Dimensions by Cube

Loading diagram...

Each business unit cube defines only the dimensions it needs — North America tracks cost centers and products, EMEA tracks departments, and APAC tracks sales channels. The corporate parent cube inherits all entity members and consolidates at a summary level. Entity and Scenario dimensions are shared across all cubes.
In both types of extensibility, the Entity and Scenario dimensions must be shared.
💡Tip
Always stub out dimensions for future use. Even if UD3 through UD8 only have a "None" member today, having the Dimension Type assigned to the cube makes future expansion as simple as adding new members. Changing cube dimensions later requires dropping and rebuilding the cube's data tables — a much more disruptive operation.

Data Unit Size and Performance

Cube design directly affects Data Unit size, which is the primary driver of calculation and consolidation performance.
A Data Unit's size is approximately the product of all non-Data-Unit dimension members: Account members × Flow members × UD1 members × UD2 members × ... × UD8 members. The Data Unit dimensions themselves (Entity, Scenario, Time, Consolidation, Parent) define which Data Unit you are in, not its size.
Key guidelines:
  • Keep Data Units under approximately 2 million records. Above that threshold, performance degrades significantly — calculations take longer, consolidation slows, and server memory pressure increases.
  • Watch for interdimensional irrelevance. Many dimension intersections will never contain valid data (e.g., Intercompany on a Deferred Tax Asset account). If those cells get accidentally populated — through a poorly written rule or by loading zeros — the Data Unit grows and performance degrades. Use input rules to prevent accidental population of invalid intersections.
  • If Data Units are too large: split entities across cubes (vertical extensibility), move high-cardinality data to relational storage, or use BI Blend for operational and external data.
⚠️Warning
Data Unit sizing is covered in depth in Understanding Data Units. Before finalizing cube design, use that guide to estimate Data Unit sizes and identify potential performance issues early.

Dynamic Cubes

Dynamic Cubes surface data in a cube structure without physically loading it into traditional cube storage. They are useful for re-aggregating existing cube data in different ways, exposing external database data for reporting, or filtering a source cube into a smaller Data Unit for performance.
The most common data binding types:
  • ShareDataFromSourceCube — Read-only reference to data in another cube. No data duplication. You can filter which members to share, creating a smaller Data Unit for focused analysis.
  • CopyInputDataFromSourceCube — Copies base-level data from a source cube into the dynamic cube as data records. Required when you need alternate rate-type or rule-type translations on the copied data.
  • Workspace Assembly bindings — Share or edit data from any source (including external systems) through Workspace Assemblies. These are the most flexible option and support scenarios like surfacing external database data in cube views or writing back edits to an external source.
Dynamic Cubes follow the same Data Unit size recommendations as standard cubes. They are not a workaround for oversized Data Units — they are a tool for flexibility and integration.

Core Dimensions

Every OneStream cube includes a fixed set of dimensions. These cannot be removed, though you can choose how many members each one contains.
DimensionPurposeABC Manufacturing Examples
EntityOrganizational structure — legal entities, cost centers, regionsUS_Corp, EMEA_Sub, APAC_Sub, ABC_Group (parent)
AccountChart of accounts — financial line items and driver accountsRevenue, COGS, SalaryExpense, FTE, AvgSalary, PricePerUnit
FlowMovement type — how data was entered or derivedEnding, Periodic, YTDInput, OpeningBalance
TimeCalendar periods2026M1 through 2026M12, 2026Q1 through 2026Q4, 2026 (year total)
ScenarioData version — separates actual results from plansActual, Budget, Forecast_Working, Forecast_M1–M12
ConsolidationCurrency translation and consolidation statusLocal, Translated, Share, Elimination
OriginData entry method — how data entered the cubeImport, Forms, AdjInput, AdjConsolidated, Elimination
IntercompanyCounterparty for intercompany transactionsNone, US_Corp, EMEA_Sub, APAC_Sub
In addition to these fixed dimensions, every cube includes UD1 through UD8 — eight user-defined dimensions that you configure for your application's specific needs.

Scenario Types

The Scenario dimension separates distinct financial processes — close, consolidation, budgeting, forecasting — into their own data spaces. But the behavior of each scenario — whether it accepts input, what time periods it covers, how data flows — is controlled by Scenario Types.
A Scenario Type is a configuration object that defines:
  • Time span — Which periods the scenario covers (e.g., Budget covers Jan–Dec 2026; Actual advances as each month closes)
  • Input frequency — Whether users enter data periodically (month by month) or as YTD totals
  • Input behavior — What kind of input the scenario accepts. Actual scenarios are typically loaded from source systems but also accept journal entries and manual adjustments during the close cycle. Budget and Forecast scenarios accept direct user input for planning.
  • Default Flow member — Controls whether input goes to Periodic, YTDInput, or another Flow member
  • Workflow behavior — Which Workflow Profile governs the submit/approve cycle for this scenario
For ABC Manufacturing's FP&A solution, the scenario setup looks like this:
ScenarioScenario Type BehaviorTime Span
ActualLoaded from ERP; accepts journal entries and adjustments during closeRolling (each month as it closes)
BudgetEditable, periodic input, annual cycle2026M1 – 2026M12
Forecast_WorkingEditable, periodic input; active workspace for the current forecast cycle2026M1 – 2026M12
Forecast_M1 – Forecast_M12One per monthly cycle; seeded with actuals for closed months, locked via NoInputPeriods2026M1 – 2026M12 (reusable across years via "All Time Periods" tracking)
💡Tip
Each month the FP&A team works in Forecast_Working: actuals are seeded for closed months and projections are entered or recalculated for open months. When the cycle is approved, Forecast_Working is copied to the corresponding Forecast_MX snapshot (e.g., Forecast_M3 for the March cycle). NoInputPeriods on each snapshot locks the actual-seeded months from editing. This preserves a full history of every forecast cycle for trend and accuracy analysis — you can compare what the March forecast looked like versus the June forecast at any time. The seeding step can be automated using OneStream's built-in Hybrid Scenario setting — configure the DataBindingType on Forecast_Working to copy or share data from the Actual scenario whenever the scenario is calculated. Two common variants exist: a YTG (Year-To-Go) Forecast, where the plan duration shrinks as the year progresses, and a Rolling Forecast, where a fixed 12-month window always looks ahead regardless of calendar position. Guide 5 in this series covers the full forecast workflow.

User-Defined Dimensions (UD1-UD8)

The eight User-Defined dimensions are where you model business-specific analytical axes. They work exactly like the core dimensions — they have hierarchies, member properties, and can be referenced in Business Rules — but their meaning is entirely up to you.
For ABC Manufacturing:
DimensionABC UsageExample Members
UD1DepartmentSales, Engineering, Operations, G_and_A, Total_Departments
UD2Product LineIndustrial, Commercial, Services, Total_Products
UD3–UD8(Available for future use)—
When to use a UD dimension vs. a relational table:
  • Use a UD dimension when the data is low-cardinality (dozens to low hundreds of members), needs to aggregate in the cube, and users need to filter or pivot by it in reports. Departments and Product Lines are classic examples.
  • Use a relational table when the data is high-cardinality (hundreds to thousands of records), is transactional in nature, or does not need to roll up through a hierarchy in the cube. Employee lists and capital project details are better suited to relational storage.

Point of View (POV)

The Point of View (POV) is the string notation OneStream uses to identify a specific cell or slice of the cube. You will see it everywhere — in Business Rule code, in Cube View definitions, and in the OneStream UI.
The format uses dimension prefixes followed by # and the member name:
plaintext
1E#US_Corp:S#Budget:T#2026M3:A#Revenue:F#Ending:C#Local:O#Forms:I#None:U1#Sales:U2#Industrial
In Business Rules, you typically specify only the dimensions you need. Unspecified dimensions default to the current Data Unit's context:
1' Read a single cell — Account and UD1 specified, others from context
2Dim cell As DataCell = api.Data.GetDataCell("A#Revenue:U1#Sales")
3Dim amount As Decimal = cell.CellAmount
4
5' Write a single cell
6api.Data.SetDataCell("A#SalaryExpense:U1#Engineering", calculatedAmount)
7
8' Use a formula expression — reads multiple cells, does math, writes result
9api.Data.Calculate("A#TotalRevenue = A#ProductRevenue + A#ServiceRevenue")
⚠️Warning
POV strings are case-insensitive for member names but the dimension prefixes must use the correct letter. The standard prefixes are: E# (Entity), A# (Account), F# (Flow), T# (Time), S# (Scenario), C# (Consolidation), O# (Origin), I# (Intercompany), U1# through U8# (User-Defined).

Data Units

A Data Unit is the fundamental unit of processing in the Finance Engine. It represents the intersection of five dimensions:
  • Entity — Which organizational unit
  • Scenario — Which data version (Actual, Budget, etc.)
  • Time — Which period (2026M3)
  • Consolidation — Which consolidation member (Local, USD, etc.)
  • Parent — Which parent entity in the hierarchy (for consolidation processing)
When OneStream calculates or consolidates data, it processes one Data Unit at a time. Your Finance Business Rule runs once per Data Unit in the scope of the operation. This means if you calculate Budget data for US_Corp across 12 months, your rule fires 12 times — once per month, each time with a different Time context.
Understanding Data Units is critical for writing efficient Finance Rules. The concept is covered in depth in Understanding Data Units.
ℹ️Info
When you call api.Data.GetDataCell("A#Revenue") inside a Finance Rule, the Entity, Scenario, Time, and Consolidation dimensions are already set by the current Data Unit. You only need to specify the dimensions you want to override.

When NOT to Use the Cube

The cube is ideal for aggregatable financial data — amounts that roll up through hierarchies and need to be sliced by multiple dimensions. But not all data belongs in the cube.
CharacteristicCubeRelational TableBI Blend
Data typeNumeric amountsAny (text, dates, numbers)Any
CardinalityLow-to-medium (dimension members)High (rows in a table)High
AggregationBuilt-in hierarchy roll-upManual (SQL or Business Rule)Dashboard-level
Input methodJournal entries, Cube Views, Business RulesSpreadsheet rules, custom dashboardsExternal systems
Best forP&L, balance sheet, KPIsEmployee lists, project details, assumptionsOperational data, external data
For ABC Manufacturing:
  • Cube — Revenue, COGS, SalaryExpense, FTE, AvgSalary by Entity × Department × Product Line × Time × Scenario
  • Relational table — Individual employee records (name, salary, start date, department, entity) for the People Plan
  • BI Blend — Sales pipeline data from Salesforce, displayed alongside the revenue forecast in dashboards

ABC Example: Dimension Design

Putting it all together, here is how ABC Manufacturing's cube is structured for their FP&A solution:
Entity Hierarchy:
plaintext
1ABC_Group
2├── US_Corp
3├── EMEA_Sub
4└── APAC_Sub
Account Dimension (simplified):
plaintext
1Total_PL
2├── Revenue
3│   ├── ProductRevenue
4│   └── ServiceRevenue
5├── COGS
6│   └── COGSAmount
7├── GrossProfit (calculated: Revenue - COGS)
8├── OpEx
9│   ├── SalaryExpense (calculated: FTE × AvgSalary)
10│   ├── BenefitsExpense
11│   └── OtherOpEx
12└── NetIncome (calculated: GrossProfit - OpEx)
13
14Driver_Accounts (no roll-up)
15├── FTE
16├── AvgSalary
17├── SalesVolume
18├── PricePerUnit
19├── COGSPercent
20└── GrowthRate
Key Design Decisions:
  • Driver accounts (FTE, AvgSalary, SalesVolume, PricePerUnit) sit under a separate parent that does not roll into Total_PL. They are inputs used by calculations, not financial line items.
  • Calculated accounts (GrossProfit, SalaryExpense, NetIncome) are computed by Finance Business Rules or Member Formulas. Users do not input data to them directly.
  • UD1 (Department) — Allows the budget to be built at the department level and rolled up. Each department manager enters drivers for their area.
  • UD2 (Product Line) — Revenue and COGS are planned by product line. Salary and OpEx are not (they are department-level only), so UD2 uses a "None" member for those accounts.
This dimension design supports the full planning workflow: seed from actuals, input drivers, calculate the P&L, consolidate across entities, and report variances — all within a single cube.
Cube Design Choice:
ABC Manufacturing uses a single cube with Horizontal Extensibility. Actual uses summary-level accounts (Revenue, COGS, OpEx aggregates), while Budget and the Forecast scenarios (Forecast_Working and the Forecast_MX snapshots) use the full detail accounts including driver accounts (FTE, AvgSalary, SalesVolume, PricePerUnit). All scenarios share the same Entity dimension and UD dimensions.
This single-cube approach works because ABC has a simple entity structure (three subsidiaries rolling up to one parent) and moderate dimensionality. As ABC grows — say, by acquiring a manufacturing company with its own entity hierarchy and plant-specific planning dimensions — they could split into Linked Cubes, with the original ABC entities in one detail cube and the acquisition in another, both rolling up to a corporate parent cube.

Related Content