RELATED and RELATEDTABLE are DAX functions that traverse active relationships between tables in a Power BI or Analysis Services data model — enabling expressions to access column values or row sets from tables related to the current evaluation context. RELATED(ColumnName) follows a relationship from the current table to a related table on the one side of a one-to-many relationship, returning the single related value — from a fact table row, RELATED(Account[AccountCategory]) returns the Account Category for that row’s Account code. RELATEDTABLE(TableName) follows the relationship in the opposite direction — from the one side to the many side — returning the set of related rows from the many-side table. Both functions operate in row context (inside iterators or calculated columns) and traverse only active relationships in the data model.
RELATED vs RELATEDTABLE
| Function | Relationship Direction | Returns | Typical Use |
|---|---|---|---|
| RELATED | Current table → related table (many-to-one, following filter direction) | Single scalar value from the related table’s column | Calculated column: enriching fact rows with dimension attributes (account category, entity region) |
| RELATEDTABLE | Current table → related table (one-to-many, against filter direction) | Table of all related rows from the many-side table | Calculated column on dimension table: count of related transactions; SUMX over related fact rows |
RELATED in Finance Model Calculated Columns
RELATED is most commonly used in calculated columns on the fact table to bring in dimension attributes that are needed for filtering or as category labels — attributes that are in the dimension table but not in the fact table’s source data. For example, an Oracle EBS GL extract may contain only the Account Code as a foreign key; the finance team’s reporting requires an Account Category (Revenue, COGS, Gross Margin, SGA, EBITDA) that is defined in the Account dimension table. A calculated column using RELATED(Account[AccountCategory]) adds the category to each fact row, enabling slicers and report filters on Account Category without requiring the BI consumer to understand the Account Code numbering scheme.
RELATEDTABLE in KPI Calculations
RELATEDTABLE is used in calculated columns on dimension tables — accessing the related fact rows for each dimension member to compute metrics that are properties of the dimension member. A calculated column on the Entity dimension table: COUNTROWS(RELATEDTABLE(GL_Actuals)) returns the number of GL journal lines for each entity — useful for an entity health check dashboard that identifies entities with unexpectedly low or high transaction volumes. SUMX(RELATEDTABLE(GL_Actuals), GL_Actuals[Amount]) on the Account dimension returns the total balance for each account — though for this use case, a measure with CALCULATE is more flexible than a calculated column.
What Goes Wrong in Practice
The most common RELATED error is using it to navigate a relationship that runs in the wrong direction — attempting to use RELATED from the one side of a relationship to the many side (which RELATED cannot do; RELATEDTABLE is required for that direction) or attempting to use RELATED across an inactive relationship (which RELATED also cannot do; USERELATIONSHIP inside CALCULATE is required for inactive relationships). Error messages from RELATED direction violations are sometimes unclear, producing “A circular dependency was detected” or “The RELATED function expects a relationship” rather than a clear indication that the relationship direction is the issue.
How Loop Wise Solutions Uses RELATED
We audit all RELATED and RELATEDTABLE usages in finance Power BI models as part of data model design review — confirming that each usage traverses the relationship in the correct direction, that the relationship being traversed is active, and that the calculated column result is genuinely needed as a column (vs. a measure that would be more flexible). Calculated columns on large fact tables using RELATED add storage overhead at each refresh; we evaluate whether a DAX measure achieves the same result with lower storage cost before recommending a calculated column approach.
Answers before you ask.
RELATED retrieves a single value from a related table's column following a many-to-one relationship — bringing a dimension attribute onto a fact row. RELATEDTABLE returns the set of related rows from the table on the many side of a relationship. One fetches a single related value; the other returns a table of related rows.
Use RELATED to pull a single attribute from the one side into the many side — for example, adding a cost centre's region to each transaction row. Use RELATEDTABLE from the one side to gather all related rows on the many side — for example, all transactions for a given entity, typically to aggregate them. Direction determines which applies.
Because RELATED works from the many side to the one side (each row has exactly one related value), while RELATEDTABLE works from the one side to the many side (returning potentially many rows). Using the wrong one for the direction of the relationship returns an error or the wrong result. The functions embody the two directions of a relationship.
RELATED enriches fact rows with dimension attributes — labelling a transaction with its entity, account, or cost-centre properties for filtering and calculation. RELATEDTABLE aggregates related detail — summing or counting the many-side rows for a given dimension member. Together they let calculations traverse the model's relationships to enrich and aggregate data correctly.