Configuring Duplicate & Merge Rules

The merge screen's field grid isn't hard-coded. A configuration table decides, object by object, which fields you compare and keep when merging two records — and it's yours to edit. This article is for the administrator who has watched an end user merge duplicate inquiries and now wants to control which fields appear in that grid, or to extend merging beyond Inquiries. After it, you'll understand the two halves of de-duplication (detection versus execution), be able to edit the field list, extend the merge tool to another object with configuration alone, and know exactly what always transfers to the surviving record no matter how the grid is configured.

How REDA de-duplication works

De-duplication has two halves, and neither works alone:

• Detection — finding the candidates. This runs on your org's standard Salesforce duplicate rules. The Potential Duplicates card shows the other members of a record's duplicate set, listing each candidate's name, owner, created date, and the rule that matched it. If no duplicate rules are active for the object, REDA gets no candidates and the card stays empty.
• Execution — the merge itself. This is REDA's own tool. It builds a compare grid — the matrix — of the configured fields across the selected records, defaults the survivor to the first record, and lets the user pick the survivor and the winning value for each field.

Detection sits entirely on the standard Salesforce side, so the usual duplicate-rule controls apply — including the inquiry's Bypass Duplicate Rules checkbox, which duplicate rules can read to let a record through without matching (it ships unchecked and lives off the page layout). If a record you expected to be flagged never appears as a candidate, that switch — or an inactive rule — is the first thing to check.

What ships configured

REDA ships merge configuration for Inquiry only, with 22 fields — all pre-selected by default. Out of the box, then, the merge tool works for Inquiries; other objects show no configured fields until an administrator adds rows. Here are the 22, grouped for readability:

Anatomy of a merge configuration record

Each configuration record adds one field to the grid for one object. A record names the object, the field to expose, whether it's default-selected (pre-ticked in the grid), and a sort order for where it appears. Two things are worth knowing:

• Only configured fields can be chosen during a merge — the merge writes only the fields you've listed onto the survivor.
• A row that names a field which doesn't exist is skipped safely. A typo won't break the screen; the field just won't appear — which also means it's easy to miss, so double-check spelling.

What always happens in a merge

Some things transfer to the survivor regardless of the field configuration:

You'll see these messages during a merge:

Extending merge to another object

The tool is extensible with configuration alone — no code — but remember both halves have to be in place.

Coming later: child-record reparenting

In this release, a merge moves activities, emails, and files or notes to the survivor — but it does not re-point other custom child records (a losing inquiry's converted deal, for instance) to the surviving record. Configurable transfer of those child records is planned for a future release. Until then, treat only activities, emails, and files/notes as moving automatically.

Worked example: two inquiries for one person

At Meridian Properties, a website form and an agent both create an inquiry for the same person — Aisha Rahman, aisha@example.com. The org's duplicate rule flags them. The agent opens the newer inquiry, sees "Potential duplicates found." on the Potential Duplicates card, and clicks Merge Duplicates. The matrix shows the 22 fields across both records. The agent keeps the older record as the survivor, picks the newer record's Mobile and Move In values, ticks delete-for the merged-away record, and confirms — "Merge completed."

The administrator's twist: marketing wants the web-attribution fields visible during merges too. The administrator adds configuration rows for those fields, with a sort order after the shipped 22, and they appear at the bottom of the matrix the next time the merge screen opens.

An inquiry record with the Potential Duplicates card — "Potential duplicates found." — listing the matched inquiry with its created date, owner, and the duplicate rule that flagged it, alongside the Merge Duplicates button.

The merge matrix: the "Survivor (record to keep)" selector at top, then the configured fields down the left and the two records' values side by side — each row a radio to pick the winning value. Differences like Inquiry Source and Move In Date are where the choice matters.

Where to go next

1. Merging Duplicate Inquiries — the end-user merge walkthrough.
2. Capturing Inquiries — where duplicates come from.
3. Customizing Inquiry Conversion — the sibling advanced-admin configuration article.
4. Accounts in REDA — a related record you may extend merging to later.
5. The REDA Admin Console — the administrator's control tower.

Frequently asked questions