Sync Airtable to Your CRM Without Duplicates

Two Systems, One Customer, No Referee

Airtable holds the operational detail. The CRM holds the sales pipeline. The same customer exists in both, and within a couple of months they disagree about the phone number, the status, and whether the deal closed.

That's not a sync problem in the technical sense. Both systems are doing exactly what they were told. The problem is that nobody decided which one is right when they differ, and without that decision no amount of wiring produces a trustworthy result.

Decide Ownership Per Field, Not Per Record

The usual advice is to pick a system of record. Sensible, and too coarse in practice, because the reason both systems exist is that each is better at something.

What works is splitting ownership by field.

Your CRM owns anything sales touches: deal stage, deal value, owner, close date, contact details as the salesperson maintains them. Airtable owns anything operations touches: project status, delivery dates, internal notes, linked records to jobs and tickets.

Then each field is written by exactly one side and read by the other. No field is writable from both. There's nothing to reconcile because conflicts are structurally impossible rather than handled.

It looks inelegant on a diagram and it survives contact with real users, which two-way sync with conflict rules generally does not. Conflict logic only fires in situations nobody tested, and the failure is silent: a value reverts and three weeks later the forecast is wrong.

The Key Field Decides Everything Else

Every sync answers one question on every run: is this record already over there. Whatever you match on is your key, and if it isn't reliable you get duplicates.

Three properties: unique, stable, always present. Email fails on stable, since people change jobs. Phone fails on format, since the same mobile arrives four different ways. Company name fails on both.

The right answer is storing each system's ID in the other. A crm_id field on the Airtable record, and an Airtable record ID field on the CRM contact. Immutable, guaranteed unique, never blank. Write it once on creation and match on it forever after.

Where you genuinely can't add a field, normalise a natural key before comparing: lowercase and trim the email on both sides, strip everything non-numeric from phones and compare the last nine digits. Do the normalisation to both the incoming value and the search value, every run. Normalising one side only is the bug that looks like a broken connector. The full version is in why your spreadsheet sync keeps creating duplicates.

The Build

Four steps per direction, and you build each direction separately even if you eventually run both.

Trigger on a change in the source. A record entering a view works well in Airtable because the filter becomes readable logic anyone can inspect.

Search the destination by the ID field. Not by name, not by email if you can avoid it.

Branch on found or not found. Update on one path, create on the other, writing the new ID back to the source so subsequent runs match cleanly.

Write only the fields that side owns. Resist mirroring everything. Every synced field is a field that can break the mapping when someone renames it, and most of them nobody reads in the second system anyway.

What Breaks After Launch

Deletes. Deleting in one system doesn't delete in the other, so the destination fills with records that no longer exist. Decide early whether deletes propagate. We prefer marking inactive, because a propagated delete is unrecoverable and someone always deletes the wrong thing once.

Picklist mismatches. Your CRM's deal stages and Airtable's status options drift apart the first time someone adds an option to one. Map them explicitly in the workflow and alert on an unmapped value rather than writing a blank.

Bulk edits. Somebody updates 400 Airtable records at once and your sync fires 400 times, hits the CRM's rate limit, fails partway, and leaves the two systems disagreeing. Cap how many records a single run can process and alert when the cap trips.

Field renames. Most connectors match fields by name. Rename one in Airtable and the sync stops populating that column silently. Match on field ID where your tool allows it.

Silence. The sync stops on a Tuesday, nothing errors, and the first symptom is a report looking slightly wrong a month later. Route failures somewhere a human reads, and add an absence check, because a job that fails to run produces no error at all. Detecting silent automation failures covers building it.

Do You Need Both Systems?

Worth asking before building anything, because sometimes the honest answer is no.

If your CRM is expensive and you're using a fraction of it while the real work happens in Airtable, the sync is maintaining a system you've already outgrown the need for. We've moved clients off a CRM entirely onto Airtable plus a connector and cut a subscription. HubSpot too expensive: what we build instead covers when that swap works and when it doesn't.

The reverse also happens. If Airtable is being asked to behave like a CRM with pipeline reporting and email tracking, you may be building CRM features badly. Airtable automation: what it can and can't do covers where the native layer stops.

Where to Start

One direction, a handful of fields, the ID written back on creation. Run it for a fortnight and check for duplicates by sorting on the key field.

Add the second direction only once the first is clean, and only for fields the other side genuinely owns. Connecting Airtable to Google Sheets and Gmail covers the same discipline applied to the reporting side.

Book a free 60-minute call and we'll map which system should own which field, pick a key that holds, and build the sync so it doesn't quietly diverge.