Clay + Salesforce
How Salesforce fits an enterprise Clay architecture — designed, governed and operated.
Salesforce is usually the system of record — which makes every Clay write a governance decision, not just a technical one. The integration architecture decides what Clay may change, what it must respect, and how provenance is preserved.
The patterns below come from production deployments where enrichment quality, deduplication and audit trails all had to survive contact with a real, messy Salesforce org.
h2:Write architecture
p:Before the first enrichment run touches production, the write path is designed: which Salesforce objects Clay may write (Account, Contact, Lead, custom objects), which fields, under what validation, and how write conflicts are resolved. Field-level security and permission sets are reviewed so the integration user can write exactly what it should — and nothing else.
h2:Deduplication & matching
p:Enrichment that creates duplicate accounts destroys the data it was meant to improve. We design match rules against your Salesforce realities — legacy account splits, global accounts, ERP-sourced records — and test them against production data volumes before go-live.
h2:Field-level governance
p:Every enriched attribute gets a source-of-truth decision: when Clay wins over Salesforce, when Salesforce wins, and what precedence looks like across providers. Audit fields capture provenance so any value on any record can be explained.
h2:Operational controls
p:Salesforce API limits are a budget. We design workflows around daily volumes, add error handling and retry behavior for failed writes, and monitor the integration so a broken enrichment run is noticed in hours, not at the end of the quarter.