# Airtable Salesforce integration

*Airtable → Salesforce*

**In short:** An Airtable to Salesforce integration turns the records your team manages in a base - leads, companies, contacts, pipeline - into matched Salesforce Leads, Accounts, Contacts, and Opportunities, and writes Salesforce IDs and closed-won status back into Airtable. Done properly it is not a Zapier zap: it resolves Airtable linked records to Salesforce lookups, maps single-select values onto restricted picklists, upserts against an external ID so nothing duplicates, respects Airtable's 5-requests-per-second and Salesforce's daily API limits, and reports per-record failures instead of silently dropping them.

## What a Airtable to Salesforce integration actually does

Airtable is where a lot of real go-to-market work actually happens. Marketing runs the lead list, partnerships tracks companies, an ops team manages a pipeline in a base because it is faster and more flexible than the CRM. Salesforce is the system of record - the place where forecasts, reporting, and the rest of the company expect that data to live.

The gap between them is manual re-keying. Someone copies a promising lead from a base into Salesforce, guesses which Account it belongs to, picks a stage from memory, and forgets to write the Salesforce ID back so nobody knows it was already done. An Airtable to Salesforce integration closes that gap: it reads the records you manage in Airtable, matches or creates the right Salesforce objects, maps every field correctly, and keeps both sides pointing at the same truth.

## What data moves

| Airtable record | Becomes in Salesforce | Notes |
| --- | --- | --- |
| Lead / inbound record | Lead (or Contact + Account) | Routed by your qualification rule; converted or created directly |
| Company / account record | Account | Matched on domain or external ID before insert to avoid duplicates |
| Person / contact record | Contact under its Account | Linked-record company resolved to the correct AccountId |
| Deal / pipeline record | Opportunity | Single-select stage mapped to the exact StageName picklist value |
| Single-select & multi-select | Restricted picklist / multi-picklist | Values mapped to API names, not free text |
| Collaborator / assignee | OwnerId | Airtable collaborator email mapped to a Salesforce User |
| Salesforce record ID | Written back to Airtable | Field on the row, so the next sync upserts instead of duplicating |
| Closed-won / stage change | Written back to Airtable | Base reflects Salesforce reality without manual updates |

The field mapping, matching keys, and picklist alignment are agreed once and encoded in the pipeline. After that, nobody maps a field or picks a stage by hand.

## The details that break naive syncs

A Zapier zap or the built-in connector gets you 80% of the way and leaves the expensive 20% on your desk:

- **Matching, not inserting.** Airtable has no unique constraint and Salesforce will happily create a second Account with the same name. Every write has to be an upsert against a stable key - domain, email, or an external ID - or you spend next quarter de-duplicating the CRM.
- **Linked records to lookups.** An Airtable link is a pointer to a `rec...` ID, not a Salesforce AccountId. A Contact or Opportunity has to have its parent resolved to the real Salesforce ID first, in the right order, or the lookup lands blank.
- **Picklists are restricted.** An Airtable single-select is free text; a Salesforce picklist is not. A stage of `Negotiation` that does not exactly match a StageName API value throws `INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST`. Multi-selects have to be joined into the semicolon format Salesforce expects.
- **Rate limits on both ends.** Airtable caps at 5 requests per second per base and locks you out for 30 seconds on a 429. Salesforce meters a daily API allocation and rewards batching through Bulk API 2.0 or Composite calls. A naive row-by-row loop hits both walls.
- **Delta, not full re-push.** Airtable has no reliable server-side changed-since filter unless you add a last-modified field and read its webhooks. Re-pushing the whole base every run wastes the API budget and risks stale overwrites.
- **Partial failures.** A Bulk job where 12 of 400 records fail a validation rule or field-level security must report those 12 with their reasons, not fail the batch and not silently drop them.

## How we build and run it

We treat this as a pipeline, not a zap. Airtable records are pulled on a schedule or by webhook, validated, matched against Salesforce, transformed into your agreed field mapping, and written through the Salesforce API - upserting on an external ID so a retry or a re-run never creates a duplicate. The Salesforce ID and any write-back fields go straight back into the base.

The pipeline is idempotent: every Airtable record carries a stable identifier and its Salesforce counterpart is keyed, so nothing is ever written twice. It runs on cloud-native, fully EU-hosted AWS infrastructure, so lead and contact data never leaves the EU - which keeps your DPA / AVV and your GDPR obligations clean.

And then we keep it running. Monitoring, alerting, incident response, and - critically - watching for Airtable Web API and Salesforce release changes are our responsibility under contract. You get a named owner and an SLA. The CRM stops depending on someone remembering to copy rows across.

## When this integration is worth building

If one person pushes a handful of records a week and a duplicate here or there is no big deal, the built-in sync or a simple zap is genuinely fine, and we will tell you so. The integration earns its place when volume climbs, when duplicate Accounts and mismatched stages start corrupting your Salesforce reporting, when linked records and owner assignment have to be right every time, or when your revenue team is spending real hours re-keying and reconciling data that a pipeline should have delivered correctly in the first place.

## Frequently asked questions

### Can I not just use Zapier, Make, or the built-in Airtable Salesforce sync?

You can, and for a low-volume one-way push of new records it is fine. It breaks down on the parts that matter: matching a record to an existing Salesforce Account instead of creating a duplicate, resolving an Airtable linked record to the right AccountId, and mapping a free-text single-select onto a restricted picklist without an INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST error. Those tools also have no real answer for partial batch failures or Salesforce validation rules. The integration moves that logic into a pipeline we own and operate.

### How do you stop duplicate Accounts and Contacts in Salesforce?

We upsert against a Salesforce external ID field rather than blind-inserting. Every Airtable record that has been synced carries its Salesforce record ID back in a dedicated field, so a re-sync updates the same record instead of creating a second one. For first-time matches we key on a stable attribute you choose - company domain, email, or an external reference - and we align with your Salesforce duplicate and matching rules so the pipeline does not fight them.

### How do Airtable single-select and linked-record fields map to Salesforce?

Single-select and multi-select values are mapped explicitly onto your Salesforce picklist API names, so an Airtable stage like Negotiation lands on the exact StageName your org expects. Linked records are the harder part: an Airtable link to a Company record is resolved to that company's Salesforce AccountId before the Contact or Opportunity is written, so the lookup relationship is correct rather than blank. We agree the mapping once and encode it.

### Is it one-way, or can Salesforce write back to Airtable?

Either. Most setups push from Airtable into Salesforce and write a few fields back - the Salesforce ID, the sync timestamp, and often the opportunity stage or closed-won flag so the Airtable base reflects reality. Full bidirectional sync is possible too, but it needs a clear rule for which system wins on a conflict. We scope that with you rather than pretending both directions are free.

### Who operates it after it goes live?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor. If Airtable changes its Web API or Salesforce ships a release that alters a field or a limit, that is our problem to fix under contract, not a surprise your revenue team discovers when records stop arriving. You get a named owner, alerting, and an SLA rather than a zap somebody has to babysit.

## Related integrations

- [monday.com ↔ Salesforce](https://seamless.engineering/integrations/monday-salesforce/): monday.com Salesforce integration
- [Salesforce ↔ Slack](https://seamless.engineering/integrations/salesforce-slack/): Salesforce Slack integration
- [Dynamics 365 ↔ Salesforce](https://seamless.engineering/integrations/dynamics-365-salesforce/): Dynamics 365 Salesforce integration
- [HubSpot ↔ Salesforce](https://seamless.engineering/integrations/hubspot-salesforce/): HubSpot Salesforce integration
- [Intercom ↔ Salesforce](https://seamless.engineering/integrations/intercom-salesforce/): Intercom Salesforce integration
- [NetSuite ↔ Salesforce](https://seamless.engineering/integrations/netsuite-salesforce/): NetSuite Salesforce integration

## Browse by system

- [All Salesforce integrations](https://seamless.engineering/integrations/salesforce/)
- [Salesforce API changelog](https://seamless.engineering/api-changelog/salesforce/): No breaking changes or deprecations in the last 90 days

## Request a scoping call

Need this integration built and permanently operated? Tell us which systems connect and what data has to move. Fixed-price scoping quote within 48 hours.

- Email: hello@seamless.engineering
- Contact form: https://seamless.engineering/#contact