How to Remove Duplicate Records in Airtable with an Undo

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

Where Airtable duplicates come from

Form submissions, CSV imports and CRM syncs each add records in their own format, so the same person or company lands in a base two or three times with different spacing, casing or suffixes. The base then reports inflated counts and filtered views hide the overlap. The consolidation habit in user list consolidation applies here: keep one master row per entity, note the source beside it and archive the review.

Where the built in extension slows down

The built in Dedupe extension finds duplicate sets inside the base and merges them one set at a time. That suits a small tidy table. On a large or messy base the review turns into repeated manual passes with no bulk preview and no undo beyond the merge step.
A pass in Sheets inverts the order: match everything at once, review the borderline band once and write back only confirmed rows.

Find the groups before changing anything

Run Find duplicates first.
It reports the groups and changes nothing, which makes it the only action that cannot damage your data. It tells you how big the problem is before you commit to a threshold. 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. That loop takes minutes and it is what keeps a bulk run precise.

Pull the base into a staging sheet

Create a personal access token in Airtable with data.records:read and schema.bases:read, add data.records:write when a write back is planned, and paste it into the Airtable card in the sidebar. Load bases lists the bases the token can reach, and the table or view follows from the picker. Pages are fetched 100 records at a time with a short pause to stay inside the Airtable limit of 5 requests per second, so a large table arrives as one working sheet. Airtable omits empty fields from its responses, so those cells arrive empty rather than as placeholders. The control list is in Airtable connector documentation.

Click Pull to staging and the connector clears the staging sheet, writes the field names as a bold header row and then the records. A pull stops at 5,000 rows and says so, so narrow the view when the base is larger. A hidden _flookup_record_id column keeps the source id for write-back: do not edit or delete it, because without it every staged row reads as new. 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 card.

Match in bulk and review once

Standardise text before matching so variants group together, then match with exact, normalised, phonetic and fuzzy measures across one column or a whole table. Start at 0.85 for names as in fuzzy matching in Google Sheets, raise the threshold toward 0.90 when false positives appear and lower it toward 0.80 when expected pairs are missed. Review the borderline band by hand and save the reviewed table to a file as the audit trail before anything writes.

When the groups look right, run Remove Duplicates on a copy of the staging sheet.
It compares the values in the column you nominate as the key and discards rows that fall within the threshold of a row it has already kept, writing one master row per entity to the output range you chose. The staging sheet itself is left as it was, so the reviewed list and the source sit side by side and the merge can be checked before anything reaches Airtable.
Those master rows are what the write back sends: the surviving values, matched row by row to the remote records on the hidden id column.

Write back in batches after a preview

Write back sends changed values to the source again in batches of ten records per call.
It updates the records the staging sheet was pulled from: only the fields that differ are sent, so untouched columns are not overwritten. Rows that exist in Airtable but not in the staging sheet are left alone, and a staged row with no record id creates a new record rather than updating one.

The first press is always Preview changes. It compares the staging sheet with the live base and reports the new, changed and unchanged counts, with a sample of the first rows before anything is written.
Apply changes starts the write, and each run applies at most 500 changes and tells you when the cap stopped the rest. Preview and apply again for the remainder.

Write back cannot merge or delete records in the base. Collapsing groups happens in the staging sheet, and the values that reach Airtable are the survivors. When duplicate rows remain in the base after the write, remove them there from the reviewed list, now that every survivor holds the complete values. Because the reviewed list was copied before the write, the record of removed rows stays on file whatever happens next.

What runs where

Flookup Data Wrangler runs as a Google Sheets add-on. Standard Data Cleaning does the matching on whatever tab is open, the Data Connectors pull sources into a staging sheet, and Data Cleaning Automation repeats either of those on a schedule.
The Airtable round trip lives entirely in that one spreadsheet: pull, dedupe, preview, apply.

The connector is 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 base is touched. A single pull stops at 5,000 records and a single run applies at most 500 changes, so a large base is worked through in passes rather than in one run.

Frequently Asked Questions