--- title: 'Syncing Data to Salesforce from Airtable Using Native Airtable Actions' description: 'Push records from Airtable into Salesforce using Airtable''s native Salesforce automation actions. Setup, field mapping, sync logic, limitations, and when to use Make instead.' canonical_url: 'https://www.business-automated.com/tutorials/sync-airtable-to-salesforce-native-actions' md_url: 'https://www.business-automated.com/tutorials/sync-airtable-to-salesforce-native-actions.md' last_updated: 2026-05-23 --- The most common ask from agencies and ops teams using [Airtable](/airtable-consultant) alongside Salesforce is "how do we keep the two in sync without buying yet another tool?" For a long time the answer was Make or Zapier in the middle. In 2026 Airtable's native Salesforce automation actions cover most of the common cases directly — you can push records from Airtable into Salesforce without leaving the Airtable automation builder. This guide walks through the setup, field mapping, the sync patterns that actually work, and the edges where you'll still want Make or a dedicated sync tool. ## What "Native Salesforce Actions" Means Airtable has two distinct Salesforce features that often get confused: | Feature | Direction | Use | | --------------------------------- | --------------------- | ----------------------------------------------------------------------------------------------------- | | **Salesforce Sync Integration** | Salesforce → Airtable | Pulls a Salesforce report into an Airtable table on a schedule (about hourly). Read-only in Airtable. | | **Salesforce Automation Actions** | Airtable → Salesforce | Create, update, or upsert Salesforce records when an Airtable automation fires. | This article is about the second one — pushing from Airtable to Salesforce. The two work well together: sync data from Salesforce in for visibility, use the automation actions to write back when something changes in Airtable. For Airtable's official documentation on the actions, see [Salesforce automation actions](https://support.airtable.com/docs/salesforce-automation-actions). ## When This Setup Is the Right Choice Native actions are the right tool when: - The sync is **one-way** from Airtable to Salesforce - The volume is **under a few hundred writes per day** - The logic is **simple** — "when a record matches these conditions, create or update in Salesforce" - You don't need **batch operations** or **complex branching** - You don't already have **Make or Zapier** in the stack If you have multi-step workflows that touch other tools as well, or you need to process hundreds of records in one run, jump to [Make](/tutorials/automate-airtable-with-make-guide) instead. The native actions optimize for simplicity, not for scale. ## Setup: Connecting Salesforce Setup is a one-time step per workspace. 1. In Airtable, open an automation and add a new action step. 2. Choose **Salesforce** from the action list. 3. Click **Connect a new Salesforce account**. 4. Sign in with your Salesforce credentials in the OAuth popup. Use a dedicated integration user if you can — it keeps an audit trail clean and avoids problems when individual users leave. 5. Approve the requested scopes (read, write, refresh token). 6. Name the connection (e.g., `Salesforce Production`). The connection is now reusable across any automation in the workspace. Field-level security in Salesforce still applies — the integration user can only read and write fields they have permission for. If your org has both a Sandbox and Production, set up two separate connections. Run your testing automations against Sandbox until you're confident, then switch the connection on each action to Production. ## The Available Actions Three action types cover most use cases. **Create Record.** Adds a new record to a Salesforce object. You pick the object (Lead, Contact, Account, custom object) and map the Airtable fields you want to populate. **Update Record.** Modifies an existing Salesforce record. Requires the Salesforce record ID — usually stored on the Airtable record from a prior creation or from a sync. **Upsert (Update or Create).** Uses a Salesforce External ID field to look up an existing record. If a match is found, update it; if not, create it. This is the pattern you'll use most when integrating two systems that should converge on the same record. For the upsert to work, the Salesforce object needs an External ID field marked as Unique and External ID. Map the Airtable record ID (or your own unique identifier) into that field. ## Pattern 1: Pushing New Records Created in Airtable The simplest case: a new Airtable record should become a new Salesforce record. **Example:** A lead comes in through an Airtable form. You want it created as a Lead in Salesforce immediately. 1. **Trigger:** When a record enters a view called `Send to Salesforce` (filter: `Status = New` and `Salesforce ID is empty`). 2. **Action: Salesforce — Create Record.** Object: Lead. Map fields: - First Name ← Airtable First Name - Last Name ← Airtable Last Name - Email ← Airtable Email - Company ← Airtable Company - Lead Source ← Airtable Source 3. **Action: Update Record (Airtable).** Set Salesforce ID to the ID returned by the Create Record step. Set Status to `Synced`. The status update at the end is what removes the record from the trigger view so it won't fire again. Storing the returned Salesforce ID is what lets future updates target the right record. ## Pattern 2: Keeping Updates in Sync When an Airtable record changes and you want the same change reflected in Salesforce. **Example:** Your team updates the deal value or stage on an Airtable Deal record. The matching Opportunity in Salesforce should update too. 1. **Trigger:** When a record matches conditions (`Stage` has changed OR `Amount` has changed) AND `Salesforce ID is not empty`. 2. **Action: Salesforce — Update Record.** Object: Opportunity. Record ID: from the Airtable Salesforce ID field. Map the changed fields. Two things to watch: - The "When a record is updated" trigger fires on **any** field change. Combine it with a condition that only fires on the specific fields you care about, otherwise you'll spam Salesforce with no-op updates. - If you have a parallel sync pulling Salesforce data back into Airtable, you can create an infinite loop (Airtable change → Salesforce update → Salesforce sync → Airtable change → ...). Prevent this by either adding a "Source of Change" field that tags whether a change originated in Airtable or in the sync, or by using a delay-and-dedup pattern. ## Pattern 3: Upsert by External ID The cleanest pattern when both systems can independently create records. 1. In Salesforce, add a custom field on the target object (e.g., Lead): `Airtable_Record_ID__c`, set as External ID and Unique. 2. In Airtable, your trigger fires whenever a record needs to be pushed. 3. Action: **Salesforce — Upsert Record.** External ID field: `Airtable_Record_ID__c`. External ID value: the Airtable record's ID. Map remaining fields. Salesforce now handles the find-or-create logic on its side. If a record with that Airtable ID already exists, it updates. If not, it creates. You don't need to track the Salesforce ID at all — the Airtable record ID is the bridge. This pattern is the most robust against drift. Records can never accidentally duplicate as long as you trust the External ID field as the join key. ## Field Mapping Rules Two surprises catch most people on first setup. **Lookup fields need IDs, not names.** Setting an Opportunity's Account requires the Account's Salesforce record ID — not the Account name. If you've stored Salesforce IDs on your Airtable records (via the sync integration or prior actions), this is a simple field map. If you haven't, you need to either look up the ID in a previous automation step or run a one-time script to backfill. **Date and datetime formats must match.** Salesforce expects ISO 8601 dates. Airtable date fields export in the right format, but if you're constructing a date from a formula, make sure it's `YYYY-MM-DD` for dates or `YYYY-MM-DDTHH:MM:SSZ` for datetimes. **Picklist values must match exactly.** A Salesforce picklist value of "Closed Won" won't accept "closed-won" or "Closed-Won." Map your Airtable single-select options to match Salesforce's picklist labels precisely, or use a formula field to normalize. **Required fields must be populated.** Salesforce will reject the action if a required field on the target object isn't supplied. Check the Salesforce object's required fields before building the action. ## Handling the Salesforce Sync Integration Side If you're using the Salesforce sync integration to pull data into Airtable as well, a few patterns make the two directions play nicely. The sync integration creates a synced table in Airtable that's read-only. You can't add Airtable-specific fields directly to it. The workaround: create a separate "shadow" Airtable table with the same primary key (Salesforce ID), linked to the synced table. Add your custom Airtable fields there. Sync frequency is about once an hour. If a Salesforce record was just updated by your Airtable action, the change won't be visible in the synced table for up to an hour. Plan automations that read from the synced table accordingly. For details, Airtable's [Salesforce sync integration documentation](https://support.airtable.com/docs/airtable-sync-integration-salesforce) covers the configuration steps and the field selection options. ## Limitations to Plan For The native actions are deliberately simple. The trade-offs: **One record at a time.** Each automation run processes one record per action call. Pushing 100 records means 100 automation runs. For a 2-3 hour batch, this is fine. For a nightly sync of thousands of records, use Make or a dedicated tool. **No batch update endpoint.** Salesforce's bulk API can update thousands of records in one call. Airtable's native action uses the standard REST API, one record per call. Each call counts against your Salesforce daily API limit (typically 15,000-100,000 per day depending on edition). **Limited error handling.** If a Salesforce call fails (validation error, missing required field, picklist mismatch), the automation logs an error and stops. There's no retry, no error queue, no fallback path. For mission-critical syncs, add an error log table in Airtable and a separate automation that watches for failures and notifies the team. **No deletes.** The native actions can't delete Salesforce records. If you need that, build a "soft delete" pattern — update the record's status field instead, and let Salesforce-side automation handle the actual deletion. **No native dedup.** The action will create a duplicate Salesforce record if your matching logic is wrong. Use upsert with External ID to prevent this. ## When to Use Make Instead The decision tree we use: - **Volume under 500 writes/day, simple one-way push:** native actions. - **Volume 500-5,000 writes/day, or need batching:** [Make](/tutorials/automate-airtable-with-make-guide). - **Two-way real-time sync with conflict resolution:** dedicated sync tool (Unito, Whalesync, Stacksync). - **Cross-system workflows that touch Salesforce and others:** Make. - **Complex routing or transformation between systems:** Make. Most setups end up using a mix. Native actions handle the routine "Airtable record is ready, push to Salesforce." Make handles the batch nightly reconciliation. A sync tool handles bidirectional contact updates if that's part of the picture. ## Troubleshooting Common Errors Five errors that come up frequently. **"INVALID_FIELD_FOR_INSERT_UPDATE: cannot specify Id in an insert call."** You're trying to set the Salesforce ID on a Create action. Salesforce assigns IDs; don't map an ID field on Create. Use Update or Upsert if you have an ID. **"REQUIRED_FIELD_MISSING."** A required field on the target object isn't in your mapping. Check the Salesforce object setup and add the field. **"INVALID_TYPE_ON_FIELD_IN_RECORD."** A picklist value or date format doesn't match what Salesforce expects. Confirm picklist values are exact, dates are ISO format. **"INSUFFICIENT_ACCESS_OR_READONLY."** The integration user doesn't have permission to write that field or object. Check field-level security and the user's profile. **"DUPLICATE_VALUE."** A unique field already has the value you're trying to insert. Either the duplicate is in Salesforce already, or two Airtable records are racing to push the same value. Use upsert by External ID to handle this cleanly. ## Where to Go Next For broader patterns, the [Airtable automation guide](/tutorials/airtable-automation-guide) covers the trigger types you'll use here. The [Make automation guide](/tutorials/automate-airtable-with-make-guide) covers what to do when the native actions hit their limits. For Salesforce-side configuration of External ID fields and field-level security, Salesforce's documentation on [External ID fields](https://help.salesforce.com/s/articleView?id=sf.custom_field_attributes.htm) is the canonical reference. ## Sitemap See the full [sitemap](/sitemap.md) for all pages.