How to Sync Salesforce Data with Clay (Two-Way)

A one-way export is a photograph. A two-way sync is a pulse.

Pull your Salesforce data into a tool once and it is stale the moment the org changes; the value is in a sync that runs both directions on a schedule. Salesforce holds the records; Clay enriches, scores, and researches them; and the loop only works if data flows in fresh and flows back clean. Get the import cadence and the write actions right and Salesforce stays continuously enriched without anyone exporting a CSV. Get them wrong and you either work off month-old data or spawn duplicates on every write. This is how to set up a two-way Salesforce sync with Clay that keeps the system of record current and never duplicates a thing.

What you need before you start:

• A Clay account and a Salesforce connection: Authenticated either as a Salesforce user via OAuth or through client credentials for a server-to-server setup.
• Write access on the objects you intend to update: And ideally a sandbox connected as a Salesforce Test Env.
• A short list of objects and fields in scope: A tight sync is a safe sync.

Step 1: Import Salesforce as a live source, not a one-time export

The first decision is what flows into Clay and how often it refreshes.

Connect Salesforce and import the objects you want to work — Leads, Contacts, Accounts, or Opportunities — as a live table source rather than a static upload. By default, Clay re-syncs Salesforce imports every 24 hours, so new records and updates in Salesforce flow into Clay on their own and trigger the action runs that re-enrich them. When you need a precise slice, a Salesforce SOQL source lets you query exactly the records you want (up to 50,000 per import) and can auto-update on a schedule too. Either way, every row carries its Salesforce Record ID, which is the key the write-back uses later.

Step 2: Enrich and score the records inside Clay

The middle of the loop is where Salesforce data becomes worth syncing back.

Once records are flowing in, Clay does the work Salesforce cannot: waterfall enrichment to fill and verify firmographics, contact data, and technographics; signal feeds to flag funding, hiring, and job changes; and Formula or Use AI columns to score and prioritize. Keep the original Salesforce value beside each enriched value so the write-back only changes what actually improved. This is the step that makes the sync worth running, because syncing stale data both directions just moves staleness around faster.

Step 3: Choose the right write action so the sync never duplicates

The write-back is where a sync turns into a mess if you pick the wrong action.

Because every imported row carries its Salesforce Record ID, the correct write is the Update record action, which keys on that Record ID and lands on the exact existing record. It updates, so there is nothing to duplicate. Two related actions cover the rest: Upsert creates-or-updates in one step but requires an external ID on the object, so use it only when you key on your own identifier; Create record is for net-new rows and is configured to prevent duplicates by default. Turn on Ignore blank values so a field you could not enrich never overwrites a populated Salesforce value with a blank.

Step 4: Scope what Clay can see and write

A sync into your system of record should touch only what it needs to.

You do not have to give Clay your whole CRM to run the loop. Connect through a restricted Salesforce user whose field-level permissions expose only the fields you enrich, and have Clay write to a dedicated set of fields (or a custom writeback object like Clay_Writeback__c) rather than your core objects. That keeps the sync auditable: you can see exactly what Clay touched, and sensitive fields stay invisible to it. The restricted user can still read what it needs and write the approved enrichment fields, so the loop runs at full strength with a fraction of the exposure.

Step 5: Test the write, then let the loop run on a schedule

A Salesforce write from Clay cannot be undone, so the first real write should not be in production.

Connect your sandbox as a Salesforce Test Env, point the write at it, and confirm the right fields update on the right records with no duplicates before you touch production. Once it passes, let the loop run: the 24-hour import keeps Clay current with Salesforce, the enrichment and scoring re-run, and the write-back keeps Salesforce current with Clay. Watch the cost as it scales, because every synced row spends Actions for the orchestration and provider results spend Data Credits, so scope the synced object set and the refresh to the records that actually need it rather than the whole org.

Kept in sync, Salesforce stays the trusted record instead of the place data goes to rot.

Common failure modes, and how to avoid them

Most two-way syncs fail the same few ways. Watch for these.

• Treating the sync as a one-time export: A single pull is stale by next week. Import Salesforce as a live source on the 24-hour refresh so changes flow both ways continuously.
• Writing with Create instead of Update: A Create run over records that already exist duplicates every row. For synced records, use Update keyed on the Salesforce Record ID; use Upsert only for external-ID matches.
• Letting blanks overwrite good data: A field you could not enrich writes an empty cell over a real value. Turn on Ignore blank values on every write.
• Giving Clay the whole CRM: Full access is more exposure than the loop needs. Connect a restricted user and write to a scoped, auditable field set.
• Testing in production: A Salesforce write cannot be undone. Run the full mapping against the Salesforce Test Env first, then promote.

Outcomes teams report after syncing their CRM with Clay