Cube Configuration

Configuring Cubes

Cubes are created at Application > Cube > Cubes. Each cube is set up and controlled through its Cube profile, which consists of five tabs covering everything from security and algorithms to dimension assignments and data access rules. For the conceptual background on cube design patterns, extensibility, and Data Unit sizing, see The OneStream Data Model. This guide covers the practical configuration of each tab.

The Five Cube Tabs

Every cube profile contains these tabs:
TabPurpose
Cube PropertiesName, type, security, consolidation/translation algorithms, FX rate defaults, Business Rules
Cube DimensionsDimension assignment by Scenario Type — the mechanism for horizontal extensibility
Cube ReferencesAuto-populated references to child cubes in a linked-cube (vertical extensibility) setup
Data AccessCell-level security rules — restrict read/write access to specific dimension intersections
IntegrationLabel and attribute dimensions, Scenario Type-specific dimension settings for data integration

Cube Properties Tab

General Settings

  • Name — Immutable after creation. Maximum 100 characters. Choose carefully — renaming requires recreating the cube.
  • Description — Free-text description. Can be changed at any time.
⚠️Warning
The cube name cannot be changed after creation. It becomes part of the underlying database table names. If you need to rename a cube, you must create a new cube, migrate the data, and delete the old one.

Cube Type

The Cube Type property assigns a type identifier to the cube. This is a grouping and tagging mechanism — it does not change the cube's behavior or enable any built-in functionality. Any cube type can be used for any purpose.
CubeTypeIdValueTypical Use
Standard0General-purpose financial cubes
Tax1Tax provision cubes
Treasury2Treasury and cash management
Supplemental3Supplemental reporting
WhatIf4What-if analysis
CubeType1–CubeType811–18Custom types — use for any purpose
ℹ️Info
The cube type is purely a label. A cube with CubeTypeId = Tax behaves identically to one with CubeTypeId = Standard. The type is useful in Business Rules where you need to branch logic by cube category — for example, api.Pov.CubeType lets you check the current cube's type at runtime.

Time Dimension Profile

The Time Dimension Profile links the cube to an accounting calendar. This determines what time periods are available in the cube (monthly, quarterly, weekly, etc.) and controls how time-based calculations like YTD and QTD roll up.

Security

  • AccessGroup — Users must belong to this security group to access the cube at all
  • MaintenanceGroup — Users must belong to this group to modify cube settings
  • UseParentSecurityForRelationshipConsolidation — When True, relationship-level consolidation members (Share, Elimination, etc.) inherit security from the parent entity rather than the child

Consolidation Algorithm Type

The consolidation algorithm controls how data flows from child entities to parent entities during the consolidation process.
TypeValueDescription
Standard0Share is calculated on the fly: (Translated + OwnerPreAdj) * %Consolidation. Eliminations use the standard hierarchy algorithm. Most common choice.
StandardWithStoredShare1Same as Standard but Share amounts are physically stored rather than calculated on the fly. Required when custom Share calculations (e.g., minority interest) are needed.
OrgByPeriodElimination2Standard Share (calc-on-fly) with Org-By-Period elimination tracking. Used when elimination history must be tracked period by period for audit purposes.
StoredShareAndOBPElimination3Combines Stored Share with Org-By-Period elimination. Full control over both Share and Elimination calculations.
Custom10000All consolidation logic is handled by Finance Business Rules. The engine does not run any default Share or Elimination processing.
diagramStandard Consolidation Flow

Loading diagram...

💡Tip
Start with Standard unless you have a specific requirement for stored share amounts or period-based elimination tracking. Standard is the best-performing option because Share is calculated on the fly — no additional data storage or processing is needed. Switch to StandardWithStoredShare when you need custom minority interest or equity pickup calculations that write to the Share consolidation member.

Translation Algorithm Type

The translation algorithm controls how local currency amounts are converted to the parent entity's currency during consolidation.
TypeValueDescription
Standard0Uses the FX rate type and rule type configured on the cube (or overridden at the scenario level) to translate all accounts. Rate types (Average, Opening, Closing, Historical) are mapped to account categories.
StandardUsingBRsForFxRates1Same as Standard but allows a Finance Business Rule to override the FX rate for any given intersection. Intersections not handled by the rule fall back to Standard logic. Common for constant-currency reporting and forecast translation.
Custom10000All translation logic is handled by Finance Business Rules. No default translation processing runs.

FX Rate Defaults

These settings define the default currency and how exchange rates are applied during translation. They can be overridden at the scenario level.
  • DefaultCurrency — The default reporting currency for the cube. Used for FX rate triangulation and intercompany matching.
Rate Type and Rule Type Defaults:
SettingApplies ToOptions
RateType for Revenues and ExpensesIncome statement accountsAverageRate, OpeningRate, ClosingRate, HistoricalRate
RateType for Assets and LiabilitiesBalance sheet accountsAverageRate, OpeningRate, ClosingRate, HistoricalRate
RuleType for Revenues and ExpensesIncome statement accountsDirect, Periodic
RuleType for Assets and LiabilitiesBalance sheet accountsDirect, Periodic
The Rule Type determines how the rate is applied:
  • Direct — Multiply each period's value by the current period's rate. Current Period Translated = Current Period Local × Current Period Rate. Standard for balance sheet accounts.
  • Periodic — Weight the calculation based on the period. Calculates the difference between YTD translated and prior YTD translated to derive the periodic translated amount. Standard for income statement accounts.
The typical default configuration:
Account CategoryRate TypeRule Type
Revenues and ExpensesAverageRatePeriodic
Assets and LiabilitiesClosingRateDirect

Business Rules

Up to eight Finance Business Rules can be attached to a cube. These rules execute during Calculate, Translate, and Consolidate operations.
The rules execute in order (BusinessRule1 through BusinessRule8) and interact with Member Formulas. During calculation, the engine processes each account — if the account has a Member Formula, that runs first, then each Business Rule fires in order. This means Business Rule logic can read values computed by Member Formulas and by earlier Business Rules. The eight rule slots are not executed back-to-back — they are spread across a broader engine sequence that interleaves them with formula passes, detailed in the DUCS section below.
💡Tip
Execution order matters. If BusinessRule2 depends on values calculated by BusinessRule1, the ordering is correct by default. But if you move a rule from slot 1 to slot 3, any rules in slots 1–2 that depended on it will now run before it. Always verify execution order when rearranging Business Rules.

Data Unit Calculation Sequence (DUCS)

The Data Unit Calculation Sequence (DUCS) is the step-by-step order in which the engine executes Member Formulas and Business Rules for each Data Unit during a Calculate operation. Understanding this sequence is essential when deciding which Business Rule slot to use and which formula pass to assign to an Account, Flow, or UD member.
The full sequence for a single Data Unit:
  1. Clear previously calculated data for the Data Unit
  2. Run the Scenario's Member Formula (seeding logic)
  3. Run reverse translations (alternate currency input Flow Members)
  4. Execute Business Rules 1 and 2
  5. Run Formula Passes 1–4 (Account formulas → Flow formulas → UD1 → … → UD8)
  6. Execute Business Rules 3 and 4
  7. Run Formula Passes 5–8
  8. Execute Business Rules 5 and 6
  9. Run Formula Passes 9–12
  10. Execute Business Rules 7 and 8
  11. Run Formula Passes 13–16
ℹ️Info
Formulas within the same pass run simultaneously and cannot depend on each other. If Account formula A needs the result of Account formula B, they must be assigned to different formula passes — for example, B in Pass 1 and A in Pass 5.
⚠️Warning
During consolidation, this entire sequence fires up to seven times per entity — once for each consolidation level (Local, Translated, OwnerPreAdj, Share, Elimination, OwnerPostAdj, TOP). Business Rule code must guard against running at unintended consolidation levels by checking api.Pov.Cons.MemberId or using If api.Pov.IsLocalCurrencyConsolidation before executing logic that should only run once.
For details on writing the Business Rules that plug into this sequence — including the difference between Calculate (which runs inside the DUCS) and CustomCalculate (which runs outside it) — see Writing Calculations.

Data Access Tab

The Data Access tab provides cell-level security — controlling which users can read or write specific dimension intersections within the cube. This is a more granular layer than entity-level or scenario-level security.

Data Cell Access Security

Each rule consists of:
ComponentDescription
UserGroupThe security group this rule applies to
MemberFilterA dimension member filter defining which cells the rule covers (e.g., A#Revenue:U1#Sales)
Access LevelNoAccess, ReadOnly, or AllAccess
CategoryAn optional label to group related rules together
Rules are evaluated in order. To get access to entity data, a user must first have Read or ReadWrite access to the entity through entity-level security. Data Cell Access Security then restricts (or confirms) access within that entity's data.
ℹ️Info
Data Cell Access Security can only restrict access — it cannot grant access beyond what entity and scenario security already allow. Think of it as an additional filter on top of the dimension-level security.

Conditional Input and Data Management Access

  • Conditional Input Rules — Control which cells can receive input based on dimension intersections. These are not security rules — they control data entry behavior (e.g., preventing input to calculated accounts).
  • Data Management Access — Control which cells can be modified by Data Management jobs.
Both use the same MemberFilter + Category structure as Data Cell Access Security.

Integration Tab

The Integration tab configures dimension settings specific to data integration and the data load process.

Cube Dimension Settings by Scenario Type

For each Scenario Type, you can configure which dimensions participate in data integration. This controls what dimensions are available when loading data into the cube for a given scenario type.

Label Dimensions

Label dimensions store non-numeric metadata alongside cube data:
  • Label — A text label attached to a data cell
  • SourceID — The source system identifier for the data cell (useful for drill-back)
  • TextValue — A free-text value associated with the cell

Attribute Dimensions

Attribute dimensions provide additional classification axes for data integration. They are configured per cube and can be used in Transformation Rules to map source data to cube intersections.
For detailed coverage of how data flows into the cube through the Import-Validate-Load pipeline, see the Data Ingestion guide series.

Accessing Cube Properties in Code

You can read cube configuration values programmatically in Business Rules:
1' Get cube info by name
2Dim cubeInfo As CubeInfo = api.Cubes.GetCubeInfo("MyCubeName")
3Dim cubeName As String = cubeInfo.Cube.Name
4Dim cubeTypeId As Integer = cubeInfo.Cube.CubeTypeId
5
6' Check the current cube's type at runtime
7Dim currentCubeType As CubeType = api.Pov.CubeType
8
9' Get FX rates for translation
10Dim fxRate As Decimal = api.FxRates.GetRate(fxRateType, timeId)

Related Content