Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Full Duplicate Error Logs entry
How-to guide

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.

By Dipojjal Chakrabarti · Founder & Editor, Salesforce DictionaryLast updated May 19, 2026

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

Allow with alertremember

User sees a duplicate warning but can save. Log entry created.

Allow with reportremember

Save proceeds silently; the duplicate is logged for later review. Lowest-friction option for sales orgs.

Blockremember

Save fails unless the user has Manage Duplicates permission and overrides. Log entry created only on override.

Bypass Sharing Rulesremember

Setting on the Matching Rule that lets it see records the running user cannot. Use only when stewards need org-wide visibility for triage.

Match across multiple objectsremember

Matching Rules can be cross-object (Lead vs Contact). Enable when sales reps create Leads that already exist as Contacts.

Gotchas
  • 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.

See the full Duplicate Error Logs entry

Duplicate Error Logs includes the definition, worked example, deep dive, related terms, and a quiz.