Ravindra BagaleCourses & study guides Track your progress

Guides

RELATED and RELATEDTABLE in Power BI DAX

By , Power BI & Data Analytics trainer LinkedIn Published: Last updated:

RELATED looks up a column from the one-side table into a many-side row; RELATEDTABLE returns the related many-side rows from a one-side row — both need an active relationship path in the model.

Chala mitrano! Relationships are the roads; RELATED and RELATEDTABLE are how DAX walks those roads. Why? Labels and counts across tables show up in every FreshBasket (fictional) model. How? Model view first, then one RELATED column and one RELATEDTABLE count. Clear and slow.

Quick answer

Vertical rules:

  1. Confirm an active many-to-one relationship (Sales → Product).
  2. On the many side: ProductName = RELATED ( Product[Name] ).
  3. On the one side: SalesCount = COUNTROWS ( RELATEDTABLE ( Sales ) ).
  4. Blank RELATED → bad keys, missing or inactive relationship.
  5. Prefer measures + relationships for totals; use RELATED for useful labels/flags.
  6. Star schema keeps these functions boring (in a good way).
RELATED       → lookup to one-side column
RELATEDTABLE  → table of many-side rows

Why RELATED, rows in / what comes out

Sales (many) and Product (one):

Sales

Order ID ProductKey Amount City
A P1 100 Mumbai
B P1 40 Mumbai
C P2 80 Nashik

Product

ProductKey Name
P1 Milk
P2 Bread
  1. Why RELATED: each Sales row needs the product name for a label.
  2. On Sales row A, RELATED ( Product[Name] ) walks the relationship. Result: Milk.
  3. On Sales row C, result: Bread.
  4. Why RELATEDTABLE: on Product row P1, RELATEDTABLE ( Sales ) returns the two Mumbai milk lines.
  5. COUNTROWS ( RELATEDTABLE ( Sales ) ) on P1 → 2. On P2 → 1.
  6. Mumbai milk sales still total 140 when you SUM Amount on those two lines.

No active relationship → RELATED returns blank. The formula did not invent a join.

RELATED needs relationship Active relationship path required Model view Active relationshipRELATED works path

Both functions need an active relationship path. Broken or missing relationships → blank RELATED results.

What do I need before this guide?

Before and after (look at the tables first)

Before RELATED Sales rows with product keys only.

Before

After RELATED Product names pulled via RELATED; Milk totals 140.

After

Model view before DAX

  1. Open Model view.
  2. Check Sales[ProductKey] → Product[ProductKey] (or your names).
  3. Active relationship line should be solid/active per Desktop UI.
  4. No path → RELATED cannot invent a join.

RELATED (many → one lookup)

RELATED lookup Many side looks up one side Sales (many) RELATEDProduct[Name] lookup

RELATED pulls a value from the one-side table into a many-side row (lookup along a relationship).

Product Name =
RELATED ( Product[Name] )
  1. Written as a calculated column on Sales (many side).
  2. Pulls the product name for this row’s key.
  3. Handy for labels; do not replace every measure with columns.

Shop analogy: RELATED is reading the product name sticker from the master shelf list onto each order slip.

RELATEDTABLE (one → many table)

RELATEDTABLE One side gets many rows Product (one) RELATEDTABLESales rows expand

RELATEDTABLE returns the many-side rows related to the current one-side row — useful inside iterators on dimensions.

Sales Rows For Product =
COUNTROWS ( RELATEDTABLE ( Sales ) )
  1. Written on Product (one side) as a column or inside a measure iterator pattern.
  2. RELATEDTABLE returns the Sales rows related to this product.
  3. COUNTROWS turns that table into a count.

RELATED vs Power Query merge

  1. Merge in Power Query — reshape before the model; stored columns.
  2. RELATED in DAX — lookup using model relationships at evaluation time.
  3. Both valid; do not maintain two conflicting category columns without a reason.

Mistakes and calm fixes

Symptom Likely cause Fix
RELATED blank No match / blank key / inactive rel Fix keys; activate relationship
Cannot use RELATED Wrong side of relationship RELATED is from many toward one
Slow model Too many RELATED columns Prefer measures; slim columns
Wrong product name Duplicate keys on one-side Enforce unique dimension keys

Ghabru naka 😅 — blank RELATED is a model detective case, not a DAX curse.

Ravindra Bagale's Tip

A common mistake: students learn RELATED and then merge the same columns in Query “for safety”, creating two truths. Pick one road for each field. Keep this in mind — model relationships are enough when the star is clean.

Practice task

  1. Draw your Sales–Product relationship on paper.
  2. Add a RELATED column for product name or category.
  3. Add a COUNTROWS ( RELATEDTABLE ( Sales ) ) style count on Product.
  4. Intentionally break the relationship in a copy file and watch RELATED go blank — then fix it.
  5. Read the course RELATED lesson and tick matching ideas.

Learn it properly

Course lessons:

Related guides: ALL family · Row vs filter context · Measures vs columns

Samajla ka? RELATED = lookup to the one side. RELATEDTABLE = many-side rows. Relationships first, then DAX. Aata pudhe jaauya — KEEPFILTERS next.

Frequently asked questions

What does RELATED do?

From a many-side row, fetches a single value from the related one-side table along an active relationship.

What does RELATEDTABLE do?

From a one-side row, returns the set of related many-side rows as a table.

Why is RELATED blank?

No match on the key, blank key, missing relationship, or inactive relationship path.

RELATED vs merge in Power Query?

Query merge reshapes before the model; RELATED looks up at evaluation time using model relationships.

Can RELATED cross many hops?

It follows a relationship path; deep snowflakes get fragile — flatter stars are easier.

Course lesson?

RELATED and RELATEDTABLE in the DAX chapter.