Master Salesforce Duplicate Management & Data Quality

💬 In plain words: Duplicate management in Salesforce relies on two interacting pieces: Matching Rules (which define what makes two records "the same") and Duplicate Rules (which dictate whether to block the save, warn the user, or just report the match). True data quality, however, requires upstream discipline—validating data at entry, deduplicating before bulk loads, and ensuring clear data ownership.

📌 Example:
Matching Rule: A fuzzy match on the Account Name plus an exact match on the Website Domain.
Duplicate Rule: BLOCK the creation of the record if a user tries to enter it manually from the UI. But, only REPORT (allow the save) if the record is coming in from a nightly ERP data load. You never want an automated data load to fail entirely just because "Acme Corp" vaguely resembles "ACME Corporation".

🔑 Key Points

• Matching vs. Duplicate Rules: A matching rule defines what a duplicate is. A duplicate rule tells Salesforce what action to take when a match is found.
• Execution Order: Duplicate rules fire after validation rules in the Salesforce Order of Execution.
• Limits at Scale: Native Salesforce matching has performance limits with Large Data Volumes (LDV). Master Data Management (MDM) tools are usually required for complex, cross-system deduplication.

🧠 Match Defines, Rule Decides: The Matching Rule provides the definition of "same." The Duplicate Rule decides the action (Allow, Alert, Block).

⚙️ The Core Concept

Salesforce's native deduplication engine is split into two halves:

• Matching Rules: These define what "same" means. You can set them to exact or fuzzy matches across specific fields you choose.
• Duplicate Rules: These determine what happens when a match is detected upon record creation or editing. You can choose to Allow the save (with a report log), Block the save entirely, or Alert the user. These rules can even run across different objects (e.g., matching Leads to existing Contacts).

At an enterprise scale, native matching has performance constraints. Therefore, in Large Data Volume (LDV) environments or multi-system master-data scenarios, architects usually implement external Master Data Management (MDM) tools to handle the heavy lifting before data ever reaches Salesforce. Remember, true data quality goes far beyond deduplication—it also relies heavily on validation rules, required fields, and strict picklist governance.

🧭 360 Card — Duplicate Management & Data Quality

• Rule: The matching rule defines "the same." The duplicate rule decides what to do about it.
• Gain: You get a single definition of sameness that can be enforced differently per channel (e.g., block in the UI, but only report on a nightly integration load).
• Price: Native deduplication prevents and flags duplicates inside Salesforce. It is not a true Master Data Management system.
• Limits: Duplicate rules execute after validation rules during a save. Crucially, they can be bypassed by API bulk loads—which is exactly how duplicates usually slip into the system.
• Mirror: Relying on users to merge records manually later is an unbounded, never-ending task that constantly grows.
• Later: Once more than two systems are fighting over customer identity, you are in MDM territory (or Data Cloud / Data 360 identity resolution for a lighter path).
• At Volume: Perform matching in a staging database before the bulk load, not inside the org. Native Salesforce rules should be your safety net for manual entry, not your primary data strategy.

⚠ INTERVIEW TRAP: Never confuse native Salesforce duplicate management with Master Data Management (MDM). Native tools prevent duplicates strictly inside Salesforce; they do not resolve complex identities or survivorship rules across multiple external systems.

❓ Core Q&A

Q: Design duplicate prevention for Accounts that are imported nightly from two different systems, plus manual user entry.

🎯 Say this first: The matching rule defines the 'same account' (fuzzy name + domain). Duplicate rules block or report based on the channel. Nightly bulk loads must run through an external deduplication step keyed on External IDs.

A: You must layer the solution. First, write a Matching Rule on the discriminating fields—for example, a normalized name, an External ID, and a fuzzy match on the address.

Next, set the Duplicate Rule to Block for manual UI entry. This is strict, but users can see the alert and adjust immediately. However, tune the imports differently. A bulk load should key on External IDs and use an upsert operation. Upserting makes deduplication exact and bypasses fuzzy matching entirely for records you already know exist. Reserve fuzzy matching only for genuinely new records.

Because native duplicate rules can throttle and crash large data loads, you must deduplicate upstream in the ETL layer for the nightly feed wherever possible. Finally, add two safety nets: a periodic deduplication report to catch anything that slips through, and a clear manual merge process for confirmed duplicates.

🚀 Scenario-Based Follow-Ups

Q1: Duplicate rules are silently allowing duplicates to be created during data loads. Why is this happening?

A: There are four common technical causes for this, plus one architectural cause:

• The Duplicate Rule is set to 'Allow' (report only) rather than 'Block'.
• The rule is being bypassed because the records are arriving via an API or context that the rule's conditions explicitly exclude.
• The fields used for matching are not populated at the time of insertion (e.g., matching on a field that the load fills in later via an update).
• The bulk operation is hitting performance limits on the matching engine and silently skipping the rule.
• The architectural cause: Upserting by External ID correctly updates an existing record. However, if two DIFFERENT source records representing the exact same real-world entity arrive carrying different External IDs, they will never match. This is why fuzzy matching or upstream MDM is required.

Q2: The business wants a 'golden record' merging data from 4 different systems. Is native Salesforce duplicate management enough?

A: No, and it never is on its own. Native deduplication only flags duplicates inside Salesforce; it lacks survivorship rules (attribute-level logic dictating "which system wins" for a specific field), bidirectional cleansing, and cross-system identity resolution.

To create a true golden record, you must either build survivorship logic in your ETL/integration layer (or use Salesforce Data Cloud) or adopt a dedicated MDM platform that feeds clean data into Salesforce. Native matching rules then become the last line of defense for manual user entry, not the engine driving the golden record.

Q3: The same customer exists in three systems with different data. What data wins?

🎯 Say this first: Deduplicate before the load, and write survivorship rules per field. "Newest wins" is not a strategy.

A: First, agree on the matching keys with the business (e.g., Tax ID, Email + Phone). Run this matching in a staging environment, never in the org. Then, define survivorship at the field level. For example: the billing address comes from the billing system, the phone number comes from the most recently updated source, and ownership comes from the active pipeline. Assemble the golden record in staging, and archive the losing records with their lineage so data is not silently lost.

Q4: The business cannot agree on survivorship rules for a specific field. How do you break the tie?

A: Put real, conflicting examples on the screen. Abstractions lead to arguments; actual data samples lead to decisions. Show them ten actual customers, each with three different versions of that field. This usually settles debates within an hour. If it is genuinely tied, keep both—put the winner on the primary record, store the loser in a related history record, and revisit the decision once you have usage data.

🔗 Connecting the Dots

Follow-up for you: Have you considered the impact of Shield Platform Encryption on your matching rules? (Hint: Probabilistic encryption breaks fuzzy matching entirely.)