Don't miss your chance to take the Fabric Data Engineer (DP-600) exam for FREE! Find out how by watching the DP-600 session on-demand now through April 28th.
Learn moreJoin the FabCon + SQLCon recap series. Up next: Power BI, Real-Time Intelligence, IQ and AI, and Data Factory take center stage. All sessions are available on-demand after the live show. Register now
Hi @ImkeF & PBI Community,
I have a scenerio where I need to merge Fact table to two different Dimentions (Lookups) tables based on condition in Fact table, I know the standard method of doing it by merging both lookup table one by one with Fact table and then create a custom column but I want to avoid it instead considering Pro approach.
Condition: If FactTable[Destination] contains "EX" then DimCountry[Country] else DimDestination[Destination]
Thanks in advance
Solved! Go to Solution.
Avoid merges in Power Query wherever possible. Let the data model do the work for you.
Hi @Numan_S ,
if you think merging tables is bad (for performance), the alternative (using a Table.SelectRows(YourDimTable, (dimTable)=> dimTable[keyColumn] = [keyColumnFactTable)) is even worse, as you are referencing the DimTable in each row of your fact table. Which would theroretically call it for each row unless you use a Table.Buffer before.
But with regards to the "Pro" approach: In standard star schemas is usually no place for fields from the dimension tables in fact tables. Fact tables should only contain the keyColumns to the dimension tables and values that are unique to the row in the fact table, like usually amounts and quantities.
If you need to reference values from a dimension table, do it in the data model like @lbendlin suggested.
If the references in the data model don't work, because every other row should use a reference to a different dimension table, then considering pivoting some columns in your fact table so that the shapes match the star schema.
Or consider merging the dimension tables into one (depending on the use case). This dimension table would have a column like "Type" with entries either "Country" or "Destination". Then your condition from above ("If FactTable[Destination] contains "EX" ") would be used to create the new (Composite-)keyColumn to that new dim table.
Imke Feldmann (The BIccountant)
If you liked my solution, please give it a thumbs up. And if I did answer your question, please mark this post as a solution. Thanks!
How to integrate M-code into your solution -- How to get your questions answered quickly -- How to provide sample data -- Check out more PBI- learning resources here -- Performance Tipps for M-queries
Hi @Numan_S ,
if you think merging tables is bad (for performance), the alternative (using a Table.SelectRows(YourDimTable, (dimTable)=> dimTable[keyColumn] = [keyColumnFactTable)) is even worse, as you are referencing the DimTable in each row of your fact table. Which would theroretically call it for each row unless you use a Table.Buffer before.
But with regards to the "Pro" approach: In standard star schemas is usually no place for fields from the dimension tables in fact tables. Fact tables should only contain the keyColumns to the dimension tables and values that are unique to the row in the fact table, like usually amounts and quantities.
If you need to reference values from a dimension table, do it in the data model like @lbendlin suggested.
If the references in the data model don't work, because every other row should use a reference to a different dimension table, then considering pivoting some columns in your fact table so that the shapes match the star schema.
Or consider merging the dimension tables into one (depending on the use case). This dimension table would have a column like "Type" with entries either "Country" or "Destination". Then your condition from above ("If FactTable[Destination] contains "EX" ") would be used to create the new (Composite-)keyColumn to that new dim table.
Imke Feldmann (The BIccountant)
If you liked my solution, please give it a thumbs up. And if I did answer your question, please mark this post as a solution. Thanks!
How to integrate M-code into your solution -- How to get your questions answered quickly -- How to provide sample data -- Check out more PBI- learning resources here -- Performance Tipps for M-queries
Avoid merges in Power Query wherever possible. Let the data model do the work for you.
Check out the April 2026 Power BI update to learn about new features.
If you have recently started exploring Fabric, we'd love to hear how it's going. Your feedback can help with product improvements.
A new Power BI DataViz World Championship is coming this June! Don't miss out on submitting your entry.
| User | Count |
|---|---|
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 |
| User | Count |
|---|---|
| 8 | |
| 6 | |
| 5 | |
| 5 | |
| 4 |