The RELATED function in DAX is used to fetch a value from a related table — specifically, it brings data from the “one” side of a relationship into the “many” side. It works only when there’s an established relationship between the two tables in your data model.
For example, suppose I have two tables — Sales and Product. The Sales table has a column ProductID, and the Product table has details like ProductName and Category. If I want to display each sale’s product name inside the Sales table, I can create a calculated column using:Product Name = RELATED(Product[ProductName])
DAX uses the existing relationship (Sales → Product via ProductID) to look up the matching ProductName for each sale.
In one of my projects, I used RELATED to bring customer-related fields like Customer[Region] or Customer[Segment] into the Sales table, which made it easier to build row-level calculations like sales commission per segment.
A challenge I faced was when there was no proper relationship between the tables — the RELATED function threw an error. It reminded me that RELATED can’t work without a direct relationship or a valid path in the model. So, I always double-check the model relationships before using it.
The limitation of RELATED is that it only works from the many side to the one side — that is, from a fact table to a dimension table. If I need to go the other way around (from one to many), I have to use RELATED TABLE instead.
In short, RELATED is like a lookup that brings a single corresponding value from another table using relationships — it helps avoid manual joins and keeps DAX expressions clean and model-aware.