Cube Views

Rows, Columns, and Member Filters

Rows and columns define the structure of a Cube View — which members appear, how they expand, and how they are organized. The Member Filter Builder is the primary tool for configuring these definitions. This guide covers row/column configuration, member filter syntax, expansions, nested dimensions, and shared definitions.

Rows and Columns Slider

The Cube View designer uses a slider to control how many dimensions are placed in rows versus columns versus the POV. Adjusting the slider moves dimensions between these three areas:
  • Rows — Dimensions that expand vertically (one member per row)
  • Columns — Dimensions that expand horizontally (one member per column)
  • POV — Dimensions that remain fixed (one member selected in the POV bar)
Each row and column definition gets a default name (Row1, Col1, etc.). Rename these to something meaningful — for example, "Accounts" or "TimePeriods" — because these names are referenced in CVC/CVR math expressions later.
💡Tip
Use meaningful names for rows and columns instead of the defaults (Row1, Col1). Names like "Accounts" and "TimePeriods" make CVC/CVR math expressions readable — GetDataCell("Accounts") / GetDataCell("TimePeriods") is much clearer than GetDataCell("Row1") / GetDataCell("Col1").

The Member Filter Builder

The Member Filter Builder is the dialog for defining which members appear in a row or column. It provides:
  • Dimension buttons — One button per dimension; click to select members from that dimension
  • Filter pane — Shows the current member filter expression
  • Preview — Displays the resolved member list

Member Selection Syntax

Member filters use a prefix-based syntax to identify dimension members:
PrefixDimensionExample
E#EntityE#Houston
A#AccountA#Revenue
S#ScenarioS#Actual
T#TimeT#2026M3
C#ConsolidationC#Local
U1# through U8#User-defined dimensionsU1#ProductA
F#FlowF#EndBal
IC#IntercompanyIC#IC_None
O#OriginO#Input
Multiple members are separated by commas: A#Revenue, A#COGS, A#GrossProfit

Member Expansions

Expansions dynamically resolve a parent member into its children at runtime. This means the Cube View automatically updates when the hierarchy changes — no manual row/column updates needed.
ExpansionDescriptionExample
.ChildrenDirect children onlyA#PL.Children — shows Revenue, COGS, OpEx (one level)
.DescendantsAll descendants at all levelsA#PL.Descendants — shows the entire PL tree
.BaseLeaf-level (base) members onlyA#PL.Base — shows only input-level accounts
.IDescendantsInclude self plus all descendantsA#PL.IDescendants — shows PL itself plus the entire tree
.IChildrenInclude self plus direct childrenA#PL.IChildren — shows PL itself plus Revenue, COGS, OpEx
diagramExpansion Results

Loading diagram...

Using the tree above:
  • A#PL.Children returns: Revenue, COGS, OpEx
  • A#PL.Base returns: Product Rev, Service Rev, Materials, Labor, Rent, Utilities
  • A#PL.IDescendants returns: PL, Revenue, Product Rev, Service Rev, COGS, Materials, Labor, OpEx, Rent, Utilities

Where Clause Expressions

Where clauses filter the results of an expansion. They appear after the expansion and use property-based conditions to include or exclude members.
plaintext
1A#PL.Descendants.Where(AccountType = Revenue)
2E#Root.Base.Where(EntityType = Legal AND IsActive = True)
Where clauses support:
  • Property comparisons: =, <>, >, <, >=, <=
  • Logical operators: AND, OR
  • String matching: Like, NotLike
ℹ️Info
Where clauses filter after expansion. The engine first expands the member list, then applies the where clause to each member. This means performance depends on the size of the expanded list, not the where clause complexity.

Nested Row Dimensions

Placing multiple dimensions in rows creates a nested (cross-product) layout. The outermost dimension expands first, and inner dimensions expand within each outer member.
For example, placing Entity (expanded) in the first row and Account (expanded) in the second row produces:
plaintext
1Houston
2  Revenue        100
3  COGS            60
4  Gross Profit    40
5Dallas
6  Revenue        120
7  COGS            70
8  Gross Profit    50
The order of row definitions matters — the first row definition is the outermost dimension. Reorder rows by dragging in the designer to change the nesting.

Nested Columns

The same nesting concept applies to columns, though it is less common. Placing Scenario and Time in columns creates a matrix:
plaintext
1              Actual           Budget
2         Jan   Feb   Mar   Jan   Feb   Mar
3Revenue    100   110   105   120   125   130

Column Dimension Examples

Columns typically show time periods, scenarios, or a combination:
  • Time across columns: T#2026M1|T#2026M2|T#2026M3 or T#2026Base.Children
  • Scenarios across columns: S#Actual|S#Budget|S#Forecast
  • Mixed: Scenario and Time nested, with calculated variance columns

POV vs Row/Column Placement

The key rule: members in the POV are fixed; members in rows/columns expand.
  • If you need to show data for a single entity across all accounts, put Entity in the POV and Account in rows.
  • If you need to compare entities side by side, put Entity in columns.
  • If you need a matrix of entities and accounts, put both in rows (nested) or one in rows and one in columns.

Shared Rows and Columns

Row and column definitions can be shared between Cube Views. When you create a row or column definition, you can mark it as shared so that other Cube Views in the same group can reference the same definition.
Benefits of shared definitions:
  • Consistency — All Cube Views using the shared definition show the same members
  • Maintenance — Update the definition once, and all referencing Cube Views update automatically
  • Templates — Create a standard row/column template and apply it across related reports
⚠️Warning
Changes to a shared row or column definition affect all Cube Views that reference it. Before modifying a shared definition, verify which Cube Views use it to avoid unintended changes to other reports.

Related Content