Using DupeBlocker for Asymmetric Duplicate Detection: Prospects vs. All Accounts

[AnthonyValidity]

When you need to detect duplicates between specific record subsets while avoiding noise from within-group matches, you'll need to implement a two-scenario approach in DupeBlocker. This technique mimics the "Filter Match Results" functionality available in the Dedupe module.

The Business Challenge

Many organizations face a common scenario: they want to catch duplicates when Prospect Accounts match ANY other account type (Customers, Partners, Vendors), but they don't want alerts for duplicates within their existing Customer or Partner populations.

Example: A new Prospect comes in matching an existing Customer - you need to know. But when a new Customer is created matching another existing Customer, that's handled through a different process and would create unnecessary alerts.

Why Filter Match Results Works in Dedupe

In the Dedupe module, the Filter Match Results feature allows you to add selection conditions that filter match groups AFTER matching occurs. For instance, you can configure Dedupe to only show match groups where "at least one record has Type = 'Prospect'."

This powerful feature lets you focus on specific duplicate scenarios without being overwhelmed by irrelevant matches.

The DupeBlocker Limitation

DupeBlocker operates in real-time as records are inserted or updated. Its filters apply to the incoming record triggering the scenario, not to the resulting match groups. You cannot directly replicate "Filter Match Results" logic in a single DupeBlocker scenario.

What you CAN'T do: Create one scenario that says "find duplicates, but only alert me if at least one record in the match is a Prospect."

What you CAN do: Create two complementary scenarios that together achieve the same outcome.

The Two-Scenario Solution

Scenario 1: Incoming Prospects vs. All Accounts

Purpose: Catch when a new or updated Prospect matches any existing account.

Configuration:

• Filter: Type = "Prospect" (or equivalent field)
• Matching Rules: Configure your standard duplicate detection criteria (Name, Address, Email, Phone, etc.)
• Action: Report as Duplicate Warning, Block, or Auto-Merge based on confidence
• Result: Any Prospect duplicate against Customers, Partners, Vendors, or other Prospects gets flagged

Scenario 2: Incoming Non-Prospects vs. Prospect Accounts

Purpose: Catch when a new or updated Customer/Partner/Vendor matches existing Prospects.

Configuration:

• Filter: Type ≠ "Prospect" (captures Customers, Partners, Vendors, etc.)
• Matching Rules: Same criteria as Scenario 1 for consistency
• Action: Same action as Scenario 1
• Result: Any non-Prospect duplicate against existing Prospects gets flagged

How This Achieves Asymmetric Matching

Together, these two scenarios ensure comprehensive duplicate detection between Prospects and all other account types:

Coverage:

• ✅ New Prospect → Existing Customer (Scenario 1)
• ✅ New Prospect → Existing Partner (Scenario 1)
• ✅ New Prospect → Existing Prospect (Scenario 1)
• ✅ New Customer → Existing Prospect (Scenario 2)
• ✅ New Partner → Existing Prospect (Scenario 2)
• ❌ New Customer → Existing Customer (Intentionally excluded)
• ❌ New Partner → Existing Partner (Intentionally excluded)

Configuration Best Practices

Keep Matching Rules Identical

Both scenarios should use the exact same matching criteria to ensure consistent duplicate detection regardless of which direction the match occurs.

Align Actions Across Scenarios

Use the same action (Block, Report, Auto-Merge) in both scenarios to maintain consistent user experience.

Document Your Logic

Add clear descriptions to both scenarios explaining they work together as a pair for Prospect-focused duplicate detection.

Test Both Directions

When testing, verify:

• Prospect matching existing Customer (triggers Scenario 1)
• Customer matching existing Prospect (triggers Scenario 2)

When to Use This Approach

This two-scenario technique is ideal when:

• You want focused duplicate alerts for specific record types without noise from other duplicates
• You need to prioritize certain record relationships (like protecting high-value Prospects)
• Different record types require different duplicate handling processes
• You want to replicate Dedupe's "Filter Match Results" behavior in real-time

Alternative Use Cases

This same pattern works for other asymmetric matching scenarios:

• High-value accounts vs. all accounts: Flag when premium accounts match anyone
• Person Accounts vs. Business Accounts: Different matching logic for B2C vs. B2B
• Verified records vs. unverified records: Protect clean data from merging with dirty data

Conclusion

While DupeBlocker doesn't offer a direct "Filter Match Results" equivalent, the two-scenario approach provides the same functionality with the added benefit of real-time duplicate prevention. By thinking through the directional nature of your duplicate detection needs, you can configure complementary scenarios that together create sophisticated, focused duplicate management.

This approach ensures your team receives actionable duplicate alerts without being overwhelmed by matches that don't require intervention, maintaining both data quality and operational efficiency.