How to Dedupe Salesforce Leads and Contacts Without Losing Data

Why native rules miss fuzzy duplicates

Salesforce matching rules catch exact and near exact pairs at creation time. They miss the pairs that accumulate through imports, web forms and integrations, where Acme Corp and Acme Corporation enter as separate records with separate activity. Those pairs then distort ownership, reporting and outreach, because each copy holds part of the history.

A local pass solves a different part of the problem. It reads a working copy out of the org, standardises and matches it with phonetic and fuzzy measures and writes back only reviewed values to records that already exist. The org stays the system of record throughout. The general export pattern is the same one in the CRM data cleaning workflow , with the difference that the desktop pulls and writes back directly instead of passing CSV files around.

What you need before you pull

Try the flow against a sandbox org first. No external review is needed for that, and a sandbox is enough to prove the query, the match threshold and the write back scope before production data is involved. Sign-in needs a connected app with the API and refresh token scopes enabled, and the consumer key goes into Settings in the app. Tokens are written to your Windows user profile beside the rest of the app data and never leave the machine.

Pull with a read only SOQL query

Enter a SOQL query in the Salesforce source, for example SELECT Id, Name, Email FROM Contact . Each page holds at most 2000 records and the remaining pages are fetched automatically, so a large object arrives as one working table. The fetched table opens as an ordinary table in the workbook, which means every other module works on it as it would on an opened file.

Keep the Id in the query. Write back matches each local row to a remote record on the column you name, usually Id or Email, and only rows that match are written. A pull remembers its source, so returning to Import names the object and refills the query for you. Only the locator is kept, never a token. The connector reference with the full control list is in Import from a Source .

Standardise and match on your own machine

Standardise first. Company suffixes, punctuation and case otherwise split groups that belong together, and matching on raw values misses them. Then match on the standardised form with exact, normalised, phonetic and fuzzy measures across one column or a whole table, with golden record merges where one survivor must keep the best values. The threshold advice in fuzzy matching in Google Sheets transfers directly: start at 0.85 for names, raise it toward 0.90 when false positives appear and lower it toward 0.80 when expected pairs are missed.

Review before anything writes. Borderline pairs around the threshold deserve a human decision, because merging two companies that share a generic name is worse than leaving them apart. Save the reviewed table to a file as the audit trail, the same way the remove duplicates workflow keeps a review sheet before it deletes anything.

Run Find duplicates before the threshold is fixed. It reports the groups and changes nothing, so the size of the problem is known before anything commits. Take a surprising pair and run Explain on it to see the nearest matches with the score for each. When the groups look right, Golden records shows the surviving choice for each one without writing it yet.

Preview write back before anything changes

Write back sends cleaned values to the source again. It updates records that already exist and nothing else: no record is created and none is deleted. Name the column that identifies a record and tick the columns to write. The app then matches each local row to a record on that column and writes only the rows that matched, in batches of two hundred through the sObject Collections endpoint.

The first press is always Preview write back. It reports how many rows matched and how many were skipped and shows the first ten changes without sending anything. Apply write back is only live after a preview, and the button then reads Confirm write back, so a write cannot happen by one press or by accident. Every write is recorded on the activity list in My Account.

Confirm once and keep an undo

A write back counts only the records the service confirmed. When a record is rejected it is named in the result and left out of the undo record, because it never changed. A write that stops part way through still records an undo for the records that did change, so those can be rolled back on their own.

Undo keeps the real previous values, captured while the records were read, rather than reconstructed later. A field that was empty before the write is restored as empty, and an applied undo is dropped from the list so the same write cannot be rolled back twice. Like the write itself, undo asks for a second press. That pair, preview before write and a second press before undo, is what makes bulk cleanup reversible where a native merge is not.

Sheets add-on or desktop

Flookup Data Wrangler exists in both places. The Google Sheets add-on cleans where the data already sits, which suits teams whose workflow lives in Sheets. The desktop pulls from Sheets, Salesforce or Airtable into a local workbook, handles Excel scale files offline and writes reviewed values back to the source. One licence covers both, so start where the data sits and move to desktop when the job needs a pull, a write back or an undo.

Start from the desktop page at Desktop when the Salesforce source is the goal. The installer is signed and the page lists the current version and file size for verification.

Frequently Asked Questions