How to Merge Salesforce Duplicate Leads Without Losing Data

This method runs entirely in Google Sheets, so there is nothing to download. Open Extensions > Flookup Data Wrangler > Data Connectors, pull the object into the staging sheet and work through the steps below in order.

Only a review sheet is needed for the shorter path, where the pull and the clean are the whole job. The Salesforce connector for Google Sheets walkthrough covers that setup in full.

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 Sheets 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 hands you the groups to merge, while 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 connector pulls the records into a staging sheet instead of passing CSV files around.

What you need before you pull

Try the flow against a sandbox org first. Choose Sandbox in the Salesforce card before connecting and create a separate Connected App in the sandbox org with the same callback URL, and the query, the match threshold and the staging sheet can all be proved before production data is involved. The Connected App needs the api and refresh token scopes, and the consumer key and secret go into the connector card in the sidebar.
Tokens are stored in the Apps Script user properties of the Google account that set them up, are never returned to the sidebar, and are removed by Clear on the connector card.

Pull with a read only SOQL query

Enter a SOQL query against the object, for example SELECT Id, Name, Email FROM Contact. The sidebar assembles the statement from the object and field picker and shows it before the pull, the LIMIT is clamped to 5,000 records and results are paged through nextRecordsUrl, so a query returns more than the first batch. Click Pull to staging and the connector clears the staging sheet, writes the field names as a bold header row and then the records.

Keep the Id in the query. It is the column the merge list is read from, and it is what ties a staged row back to the record it came from. The staging sheet is hidden from casual view but is an ordinary sheet, so rename it or copy it to a new tab whenever a review has to survive the next pull. The full control list is in Salesforce connector documentation.

Standardise and match in the staging sheet

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. 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. The output is a review list: one row per duplicate group, keeping the first occurrence of each, with the source rows beside it. Take a surprising pair and lower the threshold until the expected pairs appear, then raise it back toward 0.90 when false positives creep in.

Review the groups before anything changes

Nothing reaches the org at this stage. The connector is read only, so the only thing a run can damage is your own review.
Copy the staging sheet to a normal tab before the next pull, because Pull to staging clears it and writes the fresh result over the top. Keep that copy as the audit trail, the same way the remove duplicates workflow keeps a review sheet before it deletes anything.

Borderline pairs around the threshold deserve a human decision, because merging two companies that share a generic name is worse than leaving them apart.
Mark each group you intend to merge and each group you intend to leave alone. That list, not the staging sheet, is what the next step works from.

Merge in Salesforce from the reviewed list

Merging happens in Salesforce, where the records live. Work through the reviewed groups and combine each pair there, using the list as the instruction and the staging sheet as the reference for what each record held before the merge.

Because the sheet only ever read the org, a merge that turns out to be wrong is corrected in Salesforce rather than rolled back through a tool. Keep the reviewed list after the work is done: it records which groups were considered, which were merged and which were deliberately left apart, and that is the part a native duplicate rule never gives you.
Re-run Find duplicates after the merges and the count falls to the groups you decided to keep.

Keep the pull fresh with a schedule

Duplicate groups reform as new records arrive, so the pull has to be repeated rather than treated as a one-off. Store the pull as a Flookup automation job and the scheduler runs it on a cadence, writes the fresh result to the staging sheet and resumes if a run hits the execution limit.

• The pull stops at 5,000 records and reports that it was truncated, so a large object is better split with a LastModifiedDate filter.
• Every record lands beside the cleaning tools, which is the point: dedupe groups, standardised names and profiles all read the same staging sheet.
• It is read only. Nothing is written back to Salesforce, so the org cannot be changed by a scheduled run either.

The setup takes one Connected App and a pass that includes connectors. The walkthrough is in Connect Salesforce to Google Sheets, the scheduler is described in Data Cleaning Automation and the reference is in the Salesforce connector documentation.

What runs where

Flookup Data Wrangler runs as a Google Sheets add-on. Standard Data Cleaning cleans the tab you are on, the connectors pull Salesforce, Airtable and SQL records into a staging sheet, and Data Cleaning Automation repeats either of those on a schedule. Write-back exists for Airtable and SQL only: those two sources accept changed rows, while Salesforce is read only by design and is edited in Salesforce itself.

Connectors are included with the Extended Pass and the Team Pass. The free tier and the Essential Pass cover Standard Data Cleaning, which is enough to prove the threshold on a sample before the org is involved.

Frequently Asked Questions