Duplicate Error Logs
Duplicate Error Logs are the audit records produced by Duplicate Jobs and Duplicate Rules when a write or batch operation collides with existing data the platform considers a match.
Definition
Duplicate Error Logs are the audit records produced by Duplicate Jobs and Duplicate Rules when a write or batch operation collides with existing data the platform considers a match. Each log entry captures the source record, the matched record or set, the rule that fired, the action taken, and a timestamp, giving administrators a forensic trail of duplicate detection events without manually pulling reports against the source object. The logs surface in the Duplicate Record Sets list view and through the DuplicateRecordSet and DuplicateRecordItem objects, both queryable through SOQL and reportable through the standard report builder.
In practice, the logs are how data stewards turn an abstract Duplicate Rule into a workable backlog. A rule can fire thousands of times during a batch import or a year of front-line user activity, and the only sustainable way to triage the matches is through a queue. The logs provide that queue. They also feed the Lightning Duplicate Management UI on the record page, where end users see "Potential Duplicates" surfaced from the same backing data.
What the duplicate logs capture and how to work them
DuplicateRecordSet and DuplicateRecordItem
Two objects back the log. DuplicateRecordSet groups records the engine has identified as a cluster, one row per cluster, with a RecordCount field and a reference to the DuplicateRule that detected them. DuplicateRecordItem is the join, one row per record-to-set membership, with a foreign key to the underlying object record. Reporting against these two objects together gives you the full picture: how many sets exist, how big they are, and which records belong to which set.
Where logs come from
Two sources write to the logs. Duplicate Rules running on save, lead conversion, or API insert add entries in real time whenever the action is Allow with alert, Allow with report, or Block (block creates a log only if the user overrides via dupe override permission). Duplicate Jobs run in batch against existing data and add entries for every match they find. The same DuplicateRecordSet schema serves both paths, which is convenient for reporting and unification across real-time and batch detection.
Triage in the Duplicate Record Sets list
The Duplicate Record Sets tab, accessible from the App Launcher, shows every set the platform has logged. Data stewards open a set, review the members, and merge or unlink as appropriate. The merge action consolidates the records using the standard merge UI, while unlinking removes a record from the set without merging. Filter the list by created date, rule, or object to focus on the most recent activity.
Reporting against duplicates
Build a custom report type joining DuplicateRecordSet to DuplicateRecordItem and the source object (Account, Contact, Lead, custom). Group by rule and created date to see which rules fire most often. Group by user to see which reps produce the most duplicates. Trend the count week over week to see if data-quality interventions are working. The report type is the single most useful artifact for ongoing duplicate program management.
Retention and cleanup
DuplicateRecordSet and DuplicateRecordItem records do not auto-expire. Long-running orgs accumulate hundreds of thousands of sets, most of which were already resolved months ago. Schedule a quarterly cleanup that deletes resolved sets or sets older than a defined retention window. Without cleanup, the list view becomes unusable and the storage footprint grows without bound.
How real-time and batch logs differ
Real-time logs are written by the Duplicate Rule engine on user save, API insert, or lead conversion. Batch logs are written by Duplicate Jobs running against existing data. The two share the schema but differ in volume: real-time logs trickle in steadily, while a batch job can write tens of thousands of sets in a single run. Plan retention and review cadence to match the volume profile of each source.
Override permission and Allow records
Users with the Manage Duplicates permission can override a Block action and create the record anyway. Each override writes a log entry, which is the only way to track who bypassed the rule and for which record. Reviewing Block-overridden sets is a key data-quality control, because it surfaces the cases where a user knew they were creating a duplicate and chose to proceed.
Set up duplicate logging and the steward review loop
Reviewing duplicate error logs is a recurring data-steward task, not a one-time configuration. The workflow below sets up the queue, the reporting layer, and the retention cleanup so the logs stay useful instead of growing into noise.
- Activate the Duplicate Rule
Go to Setup > Duplicate Rules, edit the rule for the target object (Account, Contact, Lead, or custom), and confirm it is active. No active rule, no logs.
- Confirm logging is on
Open the rule and check that the action for both Create and Edit is set to Allow with alert, Allow with report, or Block. All three write log entries; Allow without any of these does not.
- Run a baseline Duplicate Job
From Setup > Duplicate Jobs, click New Job, select the matching rule, and run it against existing data. This seeds the log with everything that already exists, giving you a starting backlog.
- Open the Duplicate Record Sets tab
From the App Launcher, search Duplicate Record Sets and pin the tab to your nav. This is the queue your data stewards will work from day to day.
- Build the steward report
Create a custom report type joining DuplicateRecordSet > DuplicateRecordItem > <source object>. Build a report grouped by rule and created date, scheduled weekly to the data-quality team.
- Set up retention cleanup
Schedule an Apex batch or scheduled Flow that deletes DuplicateRecordSet records older than 90 days. Without this, the list view becomes unusable within a year.
- Train stewards on merge versus unlink
Stewards use Merge to consolidate records and Unlink to remove a record from a set without merging. Train them on when to use each; bad merges are the most common data-loss event in a duplicate program.
User sees a duplicate warning but can save. Log entry created.
Save proceeds silently; the duplicate is logged for later review. Lowest-friction option for sales orgs.
Save fails unless the user has Manage Duplicates permission and overrides. Log entry created only on override.
Setting on the Matching Rule that lets it see records the running user cannot. Use only when stewards need org-wide visibility for triage.
Matching Rules can be cross-object (Lead vs Contact). Enable when sales reps create Leads that already exist as Contacts.
- Duplicate logs do not auto-purge. Without scheduled cleanup, DuplicateRecordSet rows accumulate forever and the steward queue becomes unusable.
- Merging records does not delete the DuplicateRecordSet entry. The set remains in the log with the merged-away record still referenced. Plan reporting accordingly: filter on the survivor record's existence, not on the set status.
- Custom objects need a Duplicate Rule activated before any logs appear. Standard Matching Rules ship for Account, Contact, Lead only.
- Block action with no override permission silently fails on import. Users see an error but you may not realize the import is partial until the duplicate report shows a gap.
- DuplicateRecordSet does not show up in some legacy report types. Build a custom report type from scratch rather than expecting standard duplicates reports to surface everything.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Can a Salesforce admin configure Duplicate Error Logs without writing code?
Q2. What is the primary benefit of Duplicate Error Logs for Salesforce administrators?
Q3. Why is understanding Duplicate Error Logs important for Salesforce admins?
Discussion
Loading discussion…