Can you undo a Clay write to Salesforce?

No. Clay's documentation states that once you update or create an object in Salesforce from Clay, you cannot undo these actions. There is no rollback or dry run in the product, so the safe pattern is to prove mappings against a sandbox or a very small filtered view first, and to keep a copy of prior values for any field you intend to overwrite.

Why did my Salesforce report only import 2,000 records?

That is the documented cap. Salesforce reports are limited to 2,000 records in Clay and only tabular and matrix report types are supported, and non-SOQL-compatible list views hit the same ceiling. Nothing errors when you exceed it, so a run can look successful while silently covering only part of your segment.

What Salesforce edition do I need for Clay?

Clay does not require a specific edition, but the org needs API access. Enterprise, Unlimited, Performance and Developer include it. Professional requires the Web Services API add-on, and note that Salesforce's Additional API Calls product does not enable API access for Professional. Group and Essentials cannot obtain API access at all.

Should I turn on Duplicate Rule Override to get a run through?

We would not. The toggle bypasses your Salesforce duplicate rules for that action, and because the rules remain configured and look correct in setup, the bypass is very hard to trace later. If writes are being blocked, the blocked records are usually telling you something true about the data. Fix the match logic instead.

How do you connect Clay to Salesforce?

Clay ships a first-party Salesforce integration. You import from a list view or a report, then write back with Lookup, Create record, Upsert object, Update record and Convert lead. Two limits shape every build: imports cap at 2,000 records, and writes to Salesforce cannot be undone from Clay.

What already exists

Is there a native Clay to Salesforce integration?

The integration is first-party and covers the operations most enrichment work needs. Imports come from a Salesforce list view or a report, and Clay's own FAQ states you can update any object and any field, so custom objects and custom fields are in scope. Picklists are supported with specific formatting requirements. What separates this from the HubSpot integration is that Salesforce enforces more, and gives back less when something goes wrong.

Salesforce reports are capped at 2,000 records, and only tabular and matrix report types are supported. List views that are not SOQL-compatible hit the same 2,000 ceiling.
Imports sync every 24 hours by default. This is a scheduled loop, not a live sync.
Writes are irreversible. Clay's documentation states plainly that once you update or create an object in Salesforce from Clay, you cannot undo those actions.
Update Record requires the actual Salesforce record ID. Matching on email needs Upsert Object with Email set as the upsert field, and using the wrong action for your key is a common cause of failed or duplicated writes.
The Salesforce org needs API access, which is edition-dependent. Enterprise, Unlimited, Performance and Developer include it. Professional requires the Web Services API add-on. Group and Essentials cannot obtain it at all.
As with HubSpot, Clay's docs name a 'Pro' plan that Clay no longer sells. CRM sync is gated to Growth on the current pricing page.

The detail

What actually moves between Clay and Salesforce?

Import from a Salesforce list view or a report, subject to the 2,000 record cap

Lookup via SOQL, Create record, Upsert object, Update record, Convert lead

Any object and any field per Clay's FAQ, including custom objects and custom fields

Single-select and multi-select picklists, with formatting requirements Clay documents

Clay only sees objects and fields the connected OAuth user can see

Every synced record costs one Clay Action, separate from enrichment cost

In practice

Where Clay to Salesforce syncs go wrong

Writes cannot be undone

Clay's documentation states this directly: once you update or create an object in Salesforce from Clay, you cannot undo these actions. There is no rollback, no dry run and no staging step in the product. A misconfigured column that writes to the wrong field across 1,500 records is a Salesforce data recovery problem, not a Clay problem. This is the reason we test against a sandbox or a deliberately tiny filtered view before any first run.

Clay docs: Salesforce integration FAQs, irreversibility and duplicate rules

The Duplicate Rule Override toggle silently bypasses your dedup rules

Clay respects Salesforce duplicate rules by default, but the Create Record action exposes a Duplicate Rule Override toggle that switches them off. Someone enables it to get past a blocked run, the run succeeds, and the org's deduplication policy has been quietly disabled for that path. The rules are still configured and still look correct in Salesforce setup, which is what makes this hard to trace afterwards.

Clay docs: Salesforce integration FAQs, irreversibility and duplicate rules

Using Update Record when you meant Upsert Object

Update Record needs a real Salesforce record ID. If you are matching on email, the correct action is Upsert Object with Email configured as the upsert field. Choosing the wrong one produces either failures across the run or, worse, writes that do not land where you expected. The two actions look interchangeable in the UI and are not.

Clay community: Update versus Upsert and record ID requirements

The 2,000 record ceiling on reports and non-SOQL list views

This bites when a team builds a report intended as the source of truth for an enrichment run and quietly gets the first 2,000 rows. Nothing errors. The run completes. The remaining records were simply never in the table. Any process that assumes full coverage of a segment needs to account for this, either by chunking the source or by driving from a SOQL-compatible list view.

Clay docs: Salesforce integration overview, actions and import limits

OAuth fails in ways that do not look like permissions problems

Clay documents several: an Integration User License cannot complete the OAuth flow at all and returns OAUTH_APPROVAL_ERROR_GENERIC, the connected app may need pre-approval in the org, SSO enforcement can block the consent screen, and strict IP restrictions or session IP locking interrupt the flow. Clay's own guidance is to relax IP restrictions. All of these present as a generic approval error rather than as anything actionable.

Clay docs: Salesforce OAuth errors and IP restrictions

When not to hire anyone

Do you actually need a custom build?

The native integration is enough when you are enriching a bounded list view under 2,000 records, upserting on a stable key, working with standard objects, and a daily cadence suits you. That is a normal and perfectly good use of Clay, and it needs no help from us. It stops being enough when volume pushes past the import ceiling and needs chunking, when record types and restricted picklists mean values have to be transformed before they are safe to write, when assignment or territory rules must run against inbound records, or when the irreversibility of writes means you need a staging and approval step that Clay does not provide.

How we build it

What a Clay to Salesforce build involves

We start with a sandbox and a rollback plan, because Clay cannot undo a write. Every mapping is proven against a sandbox or a deliberately small filtered view, and we keep a record of prior values for any field we overwrite so a bad run can be reversed by us even though it cannot be reversed by Clay.

We settle the keying strategy explicitly: record ID for updates, Upsert with a defined upsert field where matching happens on email, and a documented decision about what happens when a match is ambiguous rather than letting the action decide by default.

Where the source exceeds 2,000 records we stop relying on reports and drive from SOQL through n8n, chunking the set and paginating properly, so coverage of a segment is actually complete rather than silently truncated at the ceiling.

We leave Salesforce duplicate rules on and solve blocked writes by fixing the data rather than by enabling the override toggle. Failures go to a review queue with the reason attached, and daily API consumption is monitored so an enrichment run does not quietly consume the allocation other integrations depend on.

A Clay and Salesforce pipeline is typically a three to four week build. Salesforce orgs carry more configuration history than HubSpot portals, and most of the time goes into record types, picklists and validation rules rather than the connection itself. See how we scope and price this work.

Sources

Related integrations

Clay to HubSpot Apollo to Salesforce ZeroBounce to Clay

If you are weighing whether to build this in house or have it built, read what a build like this costs, or see worked examples from real engagements. The vocabulary behind all of this is in the B2B GTM and automation glossary.

Get in touch

Tell us about your situation

Give us some context and we'll come to the conversation prepared. No generic pitch. No obligation.

We review every inquiry personally and respond within one business day.