Why Salesforce duplicate rules do not solve the cleanup problem
Buyers usually type this query after the same failure loop repeats for months: a rep gets a duplicate warning, clicks through it, creates the row anyway, and the CRM gets messier. Or the rule is so strict that it blocks real work, so the admin loosens it until it stops catching the hard cases. That is not a user-behavior problem. It is a workflow mismatch.
They evaluate record saves, not duplicate clusters
A matching rule plus a duplicate rule can alert or block a record save, but it does not hand you a cluster of six messy rows with a suggested survivor and reviewer notes.
They force you into rule design before you understand the mess
Operators start tuning field rules before they have seen how duplicates actually group across email, phone, domain, company, and shared inbox patterns.
They do not create a supervised apply loop
The native workflow does not give you approval_status, override_master_id, dry-run merge preview, receipt files, resumable state, and post-run verify as one operating loop.
What actually breaks
Duplicate rules live inside the save path. They ask a narrow question: does this row look like a duplicate of an existing row according to the matching rule? That is not the same question an operator asks during cleanup. The operator wants to know which records form one real cluster, which row should survive, which rows need manual hold, and what will happen if a merge touches routing or conversion logic.
That is why teams feel the native feature both misses obvious duplicates and creates noisy warnings. The rules are trying to compress a multi-step operational decision into a save-time check. Once the data is already messy, the right move is to step out of the save path and inspect the duplicates as a batch.
Gremlin uses a blocking-first planner for that batch step. Exact anchors define the candidate set, pair scoring creates duplicate edges, and then the operator reviews clusters in CSV or Sheets. That is a different architecture from "warn on save."
The rule is not the workflow
The audit-first loop that replaces threshold arguments
Audit and preflight
Check org identity, converted LeadStatus values, duplicate rules, and anonymous Apex support before planning or applying anything.
Cluster
Run g-gremlin dedup enterprise-plan to build a MergePlan/v2 with blocking-first candidate generation, cluster types, recommended action, survivor, anchors, and review notes.
Review
Use --cluster-review-output to hand operators a cluster queue with approval_status, override_master_id, reviewer_notes, member IDs, confidence, and golden-record suggestions.
Merge and verify
Dry-run g-gremlin sfdc merge-apply-plan by default, then execute only approved operations with --apply, receipts, resumable state, and follow-up verify checks.
What buyers usually want instead
A cluster queue they can hand to RevOps or Sales Ops.
A dry-run that previews actual merge or convert-lead operations.
A way to approve, hold, or reject ambiguous groups before anything mutates.
A receipt file plus a verify step after the run finishes.
Where to go next
Start with the pillar if you need the full model. If the immediate problem is live merge risk, jump to the audit-before-merging page. If the immediate pain is leads, use the lead merge guide.
The audit-first pillar: blocking-first planning, cluster review, supervised merge, receipts, and where native duplicate rules fall short.
How to preflight converted status, dry-run the plan, and keep lead-status side effects in view.
A candid page on account duplicate cleanup, what native rules do, and where the public Gremlin workflow stops today.
What to inspect before a merge run: blocking anchors, review queues, approvals, dry-runs, and receipts.
FAQ
Are Salesforce duplicate rules useless?
No. They are useful for save-time alerts and basic blocking. The problem is that teams often expect them to do a cleanup job they were not designed to do. They are good at warning about possible duplicates while a record is being created or updated. They are not a full audit-review-merge workflow.
Why do duplicate rules miss obvious duplicates?
Because rule-based matching is only as good as the field mappings and matching logic you encode up front. Real duplicate sets often span shared inboxes, partial phone values, slightly different names, and mixed object states. Audit-first dedupe works backward from observed clusters instead of assuming one rule will capture every messy case.
What should I use instead of duplicate rules?
If the job is entry-time prevention, keep duplicate rules. If the job is cleanup, add an audit-first layer: preflight the org, cluster duplicates offline, review the clusters in CSV or Sheets, dry-run the apply step, and verify the merges after execution.
Keep the conversation going
These pages are meant to help operators solve real problems. If you want the next guide, grab the low-friction option. If you need the implementation, not just the guide, book time.
Get the next guide when it ships
I publish architecture guides grounded in real implementations. No generic AI filler.
Use your work email so I can keep the list useful and relevant.
Need the implementation, not just the guide?
Book a 15-minute working session with Mike right on his calendar. Tooling, consulting, or a mix of both is fine.
Open Mike's calendarIf you want me to come in with context, leave your email and a short note before the call.