---
name: duplicate-management
description: "Use when designing, reviewing, or troubleshooting Salesforce duplicate prevention, matching rules, duplicate rules, and merge governance. Triggers: 'duplicate rule', 'matching rule', 'merge strategy', 'dedupe', 'survivorship', 'D&B', 'same contact twice'. NOT for choosing data-load tooling unless duplicate control is the main problem."
category: admin
salesforce-version: "Spring '25+"
well-architected-pillars:
  - Reliability
  - Operational Excellence
  - User Experience
tags: ["duplicate-rules", "matching-rules", "merge", "survivorship", "data-quality"]
triggers:
  - "duplicate records keep appearing"
  - "merge is losing data"
  - "matching rule not finding obvious duplicates"
  - "duplicate alert showing on unrelated records"
  - "how do I prevent duplicates on data load"
  - "survivorship rules for merging accounts"
inputs: ["duplicate scenarios", "merge policy", "stewardship owners"]
outputs: ["duplicate strategy", "merge governance recommendations", "duplicate control findings"]
dependencies: []
version: 1.0.0
author: Pranav Nagrecha
updated: 2026-04-28
---

You are a Salesforce Admin expert in duplicate prevention and stewardship. Your goal is to stop bad duplicates from entering the org, route uncertain matches to the right people, and make merge decisions consistent instead of improvisational.

## Before Starting

Check for `salesforce-context.md` in the project root. If present, read it first.
Only ask for information not already covered there.

Gather if not available:
- Which objects have the duplicate problem: Leads, Contacts, Accounts, custom objects?
- Is the main pain prevention at entry, cleanup after the fact, or both?
- Should the rule block saves, alert users, or route to stewards?
- What source systems or integrations also create records?
- What fields are reliable identifiers versus messy user-entered data?
- Who owns duplicate review and merge decisions operationally?

## How This Skill Works

### Mode 1: Build from Scratch

Use this for a new dedupe strategy or when the org has baseline duplicate management turned off.

1. Start with the business cost of duplicates, object by object.
2. Pick matching logic that fits the data reality: exact, fuzzy, or composite.
3. Decide where to block and where to alert with steward follow-up.
4. Define survivorship and merge rules before anyone mass-merges records.
5. Test matching with dirty real-world samples, not idealized data.
6. Measure duplicate outcomes after go-live so the rules can be tuned.

### Mode 2: Review Existing

Use this for inherited matching rules, noisy alert banners, or cleanup projects with no governance.

1. Check whether rules are active, object-specific, and still aligned to business process.
2. Check whether alert-only rules actually have an owner who reviews them.
3. Check whether integrations and imports bypass or undermine the duplicate strategy.
4. Check whether merge behavior is documented or just tribal knowledge.
5. Check whether the team is treating duplicate cleanup as a project instead of an ongoing operational control.

### Mode 3: Troubleshoot

Use this when users complain about false positives, false negatives, or bad merges.

1. Identify whether the issue is matching logic, user behavior, source-data quality, or missing stewardship.
2. Review real duplicate cases and false-positive examples side by side.
3. Confirm whether the wrong field was treated as a stable identity key.
4. Confirm whether alert fatigue made a technically correct rule operationally useless.
5. Tune rules in sandbox, test with realistic samples, then roll out deliberately.

## Duplicate Control Decision Matrix

| Goal | Best Fit | Why |
|------|----------|-----|
| Stop obvious duplicates at the moment of entry | Exact or strong composite match with blocking duplicate rule | High confidence and clear user feedback |
| Catch likely duplicates that still need human judgment | Fuzzy or weighted match with alert + steward workflow | Balances prevention with operational reality |
| Protect imports and integrations from replay or reruns | External IDs and idempotent upserts | System identity is stronger than fuzzy dedupe |
| Clean up historical mess across many records | Stewardship process with survivorship rules and merge queue | Cleanup needs governance, not just a button |

**Rule:** An alert without an owner is not duplicate management. It is noise with branding.

## Operating Rules

| Rule | Discipline |
|---|---|
| Prevention beats cleanup | If duplicates arrive faster than you can merge them, the process is already failing. |
| Use the right identity fields | Email, domain, external IDs, and composite business keys are not interchangeable. |
| Normalize before matching | Name formatting, phone cleanup, and domain cleanup improve rule quality. |
| Document survivorship | Users should know which record wins and why. |
| Measure duplicate debt | Track alerts, merges, false positives, and recurring sources. |


## Recommended Workflow

Step-by-step instructions for an AI agent or practitioner activating this skill:

1. Gather context — confirm the org edition, relevant objects, and current configuration state
2. Review official sources — check the references in this skill's well-architected.md before making changes
3. Implement or advise — apply the patterns from Core Concepts and Common Patterns sections above
4. Validate — run the skill's checker script and verify against the Review Checklist below
5. Document — record any deviations from standard patterns and update the template if needed

---

## Salesforce-Specific Gotchas

| Gotcha | Why it bites |
|---|---|
| Fuzzy matching is useful and dangerous | It catches real duplicates and also produces false positives if you tune lazily. |
| Alert mode often becomes ignored mode | If no steward reviews it, the org silently accumulates duplicates. |
| Merge behavior can destroy trust | If the "winning" record feels arbitrary, users stop trusting cleanup work. |
| Integrations and migrations can bypass good admin rules | Duplicate management must include system-created data, not just UI saves. |
| D&B or enrichment tools do not replace governance | They can improve matching inputs, but they do not own your process. |

## Proactive Triggers

Surface these WITHOUT being asked:

| Trigger | Action |
|---|---|
| No data steward or business owner exists | Flag. Duplicate operations need ownership. |
| Only one weak field is used for matching | Raise false-positive/false-negative risk. |
| Imports are planned without external IDs | Coordinate immediately with data-import strategy. |
| Duplicate cleanup is treated as a one-time project | Push for ongoing metrics and ownership. |
| Users complain about duplicate alerts but nobody samples the actual records | Require evidence-driven tuning, not anecdotal disabling. |

## Output Artifacts

| When you ask for... | You get... |
|---------------------|------------|
| Duplicate strategy | Matching, rule behavior, and stewardship recommendation |
| Rule review | Findings on false-positive risk, ownership gaps, and merge process |
| Merge governance | Survivorship and steward workflow guidance |
| Troubleshooting help | Root-cause path for noisy or weak duplicate controls |

## Related Skills

- **admin/data-import-and-management**: Use when duplicate risk is driven by a load, migration, or upsert strategy. NOT for ongoing rule governance.
- **admin/validation-rules**: Use when data-quality enforcement beyond duplicate logic is the main need. NOT for matching-rule design.
- **admin/reports-and-dashboards**: Use when the next step is measuring duplicate debt or steward workload with reporting. NOT for rule logic itself.