Data Analytics
Timespan
explore our new search
​
Power BI DAX: RELATED vs RELATEDTABLE
Power BI
Nov 22, 2025 1:05 PM

Power BI DAX: RELATED vs RELATEDTABLE

by HubSite 365 about Pragmatic Works

Microsoft Power BI DAX: use RELATED and RELATEDTABLE to combine tables, build calculated columns with SUMX and AVERAGEX

Key insights

  • RELATED and RELATEDTABLE overview:
    These DAX functions let you move data across tables in Power BI using table relationships. RELATED returns a single value from the "one" side; RELATEDTABLE returns all matching rows from the "many" side.
  • When to use RELATED:
    Use it in calculated columns or measures to fetch attributes (like product name or customer info) from a lookup table into a detail table. It works in a many-to-one direction, similar to a model-aware VLOOKUP.
  • When to use RELATEDTABLE:
    Use it with aggregators and iterators (for example COUNTROWS, SUMX, AVERAGEX) to collect all related detail rows for a given lookup row, then sum or count them as needed—e.g., count orders per customer or gather sales rows for a category.
  • Fixing totals and averages:
    Use SUMX with quantity included to get correct total sales per row, and use AVERAGEX to compute average sales per order. These iterator functions work well with RELATEDTABLE to apply row-by-row calculations.
  • Common mistakes to avoid:
    Don’t mix up direction or context—RELATED needs a row context and returns a scalar; RELATEDTABLE changes context and returns rows. Check relationship cardinality and direction before writing the formula.
  • Practical tips and recap:
    Ensure model relationships are set up correctly, test with sample data, and pick RELATED for single lookups and RELATEDTABLE when you must aggregate or iterate over related rows.

Pragmatic Works released a concise tutorial on YouTube that clarifies two essential DAX functions in Power BI: RELATED and RELATEDTABLE. In the video, trainer Justin Vogel walks viewers through how these functions navigate relationships across tables and when each one is appropriate. Consequently, the session targets both beginners who need a model-aware equivalent of Excel lookups and intermediate users sharpening aggregation techniques. Overall, the presentation balances clear demonstrations with practical warnings about common mistakes.


Overview of the Video

The tutorial opens by framing the typical problem: you need a column in one table but the data lives in another. Then, the video explains how properly defined one-to-many relationships in the data model allow RELATED and RELATEDTABLE to work reliably. In addition, Vogel emphasizes that these functions are model-aware, meaning they rely on relationship direction and cardinality to return correct results. Therefore, viewers should ensure their model relationships are configured before applying these functions.


Next, the presenter outlines a practical starter file and a sequence of hands-on tasks to practice with the sample dataset. Viewers follow examples that bring customer details into an orders table, count orders per customer, and compute totals and averages while including quantity. As a result, the tutorial makes the concepts tangible rather than purely theoretical, which helps bridge the gap between learning and real-world application. The clear timestamps included in the video guide viewers to specific sections for quick review.


How RELATED Works

Vogel demonstrates that RELATED functions like a model-aware VLOOKUP by fetching a single related value from the 'one' side of a relationship into the current row. Thus, when you have a row context on a fact or detail table, RELATED returns the corresponding scalar attribute, such as a product name or customer segment. Furthermore, the video explains that RELATED respects relationships even if visual filters change, because it performs lookups based on the model rather than on transient visual filters. Consequently, this function simplifies calculated columns that need to surface attributes from lookup tables.


However, Vogel also warns about misuse: RELATED only works in many-to-one directions, and calling it without the proper relationship will produce errors or wrong results. In practice, this means developers must avoid creating ambiguous or inactive relationships that break expected behavior. Moreover, when performance matters, fetching many scalar lookups across huge tables can still add overhead in calculated columns, so designers should consider alternatives for large-scale scenarios. Ultimately, RELATED is ideal for straightforward attribute retrieval when model relationships are clear.


How RELATEDTABLE Works

By contrast, RELATEDTABLE returns a table of related rows from the many side of a relationship, which makes it useful inside iterator and aggregation functions. Vogel shows how combining RELATEDTABLE with functions like COUNTROWS, SUMX, and AVERAGEX enables correct counts and sums for related records. For example, calculating orders per customer requires pulling all order rows related to a customer, which RELATEDTABLE provides as a working set for aggregation. Therefore, this function shifts context from a single row to a filtered table of related rows.


Still, the video notes tradeoffs: using RELATEDTABLE over very large related tables can strain performance when measures run frequently in visuals. Consequently, designers should weigh whether to use measures with optimized filter context or pre-aggregated columns depending on report needs. Additionally, developers must understand row versus filter context to avoid common pitfalls when nesting iterators. In short, RELATEDTABLE offers powerful aggregation but demands careful model and performance planning.


Practical Demonstration and Examples

Vogel walks through concrete examples that illustrate both correct and incorrect approaches, helping viewers recognize subtle mistakes around context transition. He first brings customer attributes into an orders table using RELATED, and then computes order counts per customer with RELATEDTABLE plus COUNTROWS. Next, the session fixes a common total sales error by applying SUMX together with quantity, and finally derives average sales per order using AVERAGEX. These step-by-step demos underline how different functions must be combined to produce reliable business metrics.


In addition, Vogel contrasts “bad” versus “good” column designs to help viewers spot real mistakes, such as mixing row and filter contexts improperly. He also highlights the value of practicing with the starter file so users can reproduce each step and validate outcomes. Consequently, the examples not only teach syntax, but also promote disciplined modeling habits that improve long-term maintainability. This hands-on structure helps bridge conceptual learning and practical application.


Tradeoffs and Challenges

Balancing correctness, performance, and model simplicity forms the core tradeoff when choosing between RELATED and RELATEDTABLE. On one hand, RELATED offers fast attribute lookups when relationships are clean, but it cannot aggregate related records. On the other hand, RELATEDTABLE supports aggregation yet can become heavy on large datasets, especially when nested inside iterators used in many visuals. Therefore, report authors must decide whether to pre-aggregate, optimize relationships, or accept runtime computation based on their specific scale and latency requirements.


Moreover, common challenges include handling many-to-many relationships, inactive links, and context confusion between calculated columns and measures. To mitigate these issues, Vogel recommends clear modeling, documenting relationship direction, and testing with realistic data volumes. Consequently, investing time up front in model design reduces downstream debugging and performance tuning. Ultimately, the best approach depends on the dataset size, report interactivity needs, and maintenance constraints.


Conclusion

The Pragmatic Works video delivers a focused, practical lesson on when and how to use RELATED and RELATEDTABLE in Power BI. By combining clear demos with examples of common errors, the tutorial equips viewers to apply both functions with confidence while recognizing tradeoffs. In addition, the emphasis on model relationships, iterator functions, and performance considerations provides a useful roadmap for real-world reporting. Consequently, developers and analysts can use these insights to build more accurate and efficient DAX calculations.


Power BI - Power BI DAX: RELATED vs RELATEDTABLE

Keywords

RELATED DAX, RELATEDTABLE DAX, RELATED vs RELATEDTABLE, Power BI RELATED function, Power BI RELATEDTABLE examples, DAX relationship functions, DAX RELATED tutorial, RELATEDTABLE performance