Infosys Power BI Interview: Fixing Wrong Results From Bad Relationships

by

Infosys: How Do You Troubleshoot Incorrect Results in Power BI When Relationship Directions Are Misconfigured?

This is one of the most commonly asked questions in Infosys Power BI, Data Analyst, and BI Developer interviews. Infosys manages large enterprise BI implementations where Power BI models contain dozens of tables, complex relationships, multiple fact tables, role-playing dimensions, and advanced DAX logic. Even a single misconfigured relationship direction can produce completely incorrect results, leading to severe reporting issues.

Troubleshooting incorrect results caused by misconfigured relationships requires a deep understanding of:

  • Filter propagation and relationship directions
  • One-to-many vs many-to-many relationships
  • Single vs bi-directional filtering
  • Ambiguous paths between tables
  • Fact-to-fact relationships and bridge tables
  • Role-playing date tables
  • DAX evaluation context
  • Cardinality and filter flow

Recommended: Read our detailed TCS guide on handling complex DAX circular dependency issues .

For Microsoft’s official modeling guidance, visit Power BI Relationship Best Practices on Microsoft Learn .

1. Why Infosys Interviewers Ask This Question

Power BI relationship misconfiguration is one of the top root causes of incorrect:

  • Totals and subtotals
  • Aggregations such as SUM, AVG, MAX, MIN
  • Filter behavior in slicers
  • Unexpected blank rows
  • Incorrect DAX results
  • Mismatched values between visuals

Infosys interviewers want to check whether you can diagnose issues in large enterprise models and fix them logically — not randomly.

2. Understanding Relationship Directions in Power BI

2.1 Single-Direction Filtering

Filter flows from the one-side (dimension) to the many-side (fact table). This is the ideal setup for star schemas.


DimCustomer (1)  --->  (*) FactSales

2.2 Bi-Directional Filtering

Filters flow in both directions. Useful sometimes, but dangerous in most real models.


DimCustomer <----> FactSales

2.3 Many-to-Many Relationships

M2M relationships introduce ambiguity and unexpected results when used incorrectly or without bridge tables.

2.4 Ambiguous Relationship Paths

When two tables can be connected through more than one path, Power BI produces ambiguous filters.


DimDate ---> FactSales  
DimDate ---> FactReturns  
FactSales ---> FactReturns   (Ambiguous Path)

This almost always produces incorrect results unless managed properly.

3. Real Examples of Wrong Results Due to Incorrect Relationship Direction

3.1 Example: Wrong Sales Amount Because Filter Doesn’t Propagate

Model:


DimProduct <--single-- FactSales  
FactSales <--single-- FactReturns

If you choose Product Category from DimProduct, the filter flows to FactSales but NOT to FactReturns.

This produces mismatched totals in visuals:

  • Sales shows filtered results
  • Returns shows ALL data

3.2 Example: Wrong YTD Because Bi-Directional Makes Calendar Filter Unpredictable

If DimDate ↔ FactSales is bi-directional, and FactSales ↔ FactBudget is also bi-directional, DAX time intelligence becomes unstable.

3.3 Example: Wrong Customer Count Due to Many-to-Many Join


Customer <---> Sales  
Customer <---> SupportTickets

You will get inflated distinct counts.

4. Step-By-Step Troubleshooting Strategy (Infosys Level)

Infosys expects a structured debugging approach.

4.1 Step 1 — Identify the Incorrect Visual

Check visuals where totals or filters don’t behave correctly.

4.2 Step 2 — Identify All Tables Used in That Visual

List all related dimension and fact tables.

4.3 Step 3 — Open the Model View & Examine Relationship Arrows

Look for:

  • Bidirectional relationships
  • Inactive relationships
  • Many-to-many relationships
  • Ambiguous paths

4.4 Step 4 — Validate Cardinality

Ensure:

  • Dimensions have unique keys
  • No duplicates in dimension keys
  • Fact tables do NOT become dimensions accidentally

4.5 Step 5 — Fix Filter Flow Direction

In most cases, use:


One-to-Many  
Single Direction (Dimension → Fact)

4.6 Step 6 — Resolve Ambiguous Paths

Use:

  • Bridge tables
  • Inactive relationships
  • USERELATIONSHIP() in DAX for specific visuals

4.7 Step 7 — Use CROSSFILTER in DAX Sparingly


SalesWithBothDirections =
CALCULATE(
    [Total Sales],
    CROSSFILTER(DimCustomer[CustomerID], FactSales[CustomerID], BOTH)
)

Use this ONLY within a measure — never permanently in the model.

5. Final Interview-Ready Answer (Infosys Style)

“When Power BI returns incorrect results, I first analyze the visuals and identify the tables involved. I inspect relationship directions, cardinality, inactive relationships, and ambiguous filter paths. Most issues originate from wrong bidirectional filters or many-to-many relationships. I correct the model by ensuring dimension-to-fact single-direction filtering, cleaning surrogate keys, resolving ambiguous paths with bridge tables, and enabling inactive relationships only through USERELATIONSHIP() inside DAX. This ensures accurate filter flow, stable DAX calculations, and reliable enterprise reporting — which is essential in Infosys-level BI projects.”

6. Conclusion

Infosys expects candidates to demonstrate deep data modeling knowledge. Understanding how relationship directions impact filter propagation is one of the most critical skills in Power BI development. With the troubleshooting strategy in this guide, you can confidently diagnose and fix incorrect results caused by relationship misconfigurations in real Infosys projects.