Merge Customer and Contacts with fuzzy matching in Power BI
Short answer
D Enable fuzzy matching when merging Customer and Contacts so unsanitized Customer_Name and Customer Name values can be matched despite spelling, casing, spacing, or punctuation differences.
Question
The Customer table contains the following columns:
• Customer_Name
• Customer ID
• Website
The Contacts table contains the following columns:
• Contact ID
• Contact Email
• Contact Name
• Customer Name
A web-based contact form is used to fill the Contacts table. The data is not sanitized.
You need to create a merge for the Customer and Contacts tables.
What should you do?
Key Takeaways
It tests whether you can distinguish exact merge keys from approximate text matching; the trap is treating join kind or disabling fuzzy matching as a fix for dirty name data.
This PL-300 scenario tests Power BI merge options for unsanitized contact data; the correct choice is to enable fuzzy matching (D) when merging Customer and Contacts.
Common mistake: Choosing Left Outer (C) only controls which rows survive the merge; it does not reconcile misspelled or inconsistently formatted names, so unmatched Contacts rows remain unmatched.
Expert Analysis
The real boundary: exact key vs approximate text The deciding issue is not how many rows survive the merge but how Power BI decides that a Contacts row belongs to a Customer row. Exact matching requires the selected text values to agree after ordinary case handling; fuzzy matching compares text and scores similarity, allowing minor differences such as spelling, spacing, punctuation, or word order. The web-based contact form is unsanitized, so the practical merge key—Customer_Name against Customer Name—can vary. That places the scenario on the fuzzy side.
What the join kind controls A Full Outer join (A) or Left Outer join (C) determines which unmatched rows are kept. Neither repairs a name that was typed differently. A Left Outer join could keep every Customer row plus matching Contacts, but a poorly entered contact still appears as unmatched. Full Outer just exposes unmatched rows from both sides; it does not make them match.
Why D, not B Enabling fuzzy matching (D) is the action that gives the merge tolerance for dirty names. Disabling fuzzy matching (B) would force exact comparison and increase missed matches. Use an exact join on stable keys such as Customer ID only if a clean ID exists on both sides; Contacts supplies Contact ID, not Customer ID, so the text name is the practical key here. D is correct.
Official Reference
- https://learn.microsoft.com/en-us/power-query/merge-queries-overview
- https://learn.microsoft.com/en-us/powerquery-m/table-fuzzyjoin
These links open the official vendor documentation in a new tab.
Exam Strategy
When a stem says source data is unsanitized, dirty, or entered by users, check whether the merge key is text with likely spelling or format variance. Separate row-retention choices such as Left Outer or Full Outer from the matching method: join kind cannot repair name mismatches. Use fuzzy matching when exact keys would drop valid pairs, and reserve exact joins for clean, standardized keys such as IDs.
Frequently Asked Questions
Why does enabling fuzzy matching fix the Customer and Contacts merge?
Does a Left Outer join solve mismatched customer names?
When should I not use fuzzy matching?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 1 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 1
-
Prasanth_S31 👍 1 Answered DAnswer is Correct
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All PL-300 Questions
Access 116 questions with complete answers and detailed explanations.
View Full PL-300 Practice Test →