ZapBounce and Salesforce
Salesforce splits the same person across objects. A Lead has an Email field, a Contact has another, and after conversion you have both with no guarantee they agree.
That shape decides how verification fits: the verdict belongs on the record as a field, so it survives conversion and can be read by assignment rules, validation rules and reports.
ZapBounce connects to Salesforce three ways. Scheduled Apex or your middleware calls the API and writes verdicts back. A CSV or XLSX export goes through a bulk upload and comes back as a results CSV you match to your records on the email column. Zapier runs a check whenever a Lead or Contact is created or its email changes.
The same address exists on several objects with different histories
A Lead converted to a Contact leaves the Lead record behind, often with an address that was never re-checked. Reports built on Leads and reports built on Contacts then disagree about the same person.
Salesforce stores no deliverability verdict of its own. Its EmailBouncedDate and EmailBouncedReason fields populate only after a send has already failed, and only when bounce management is switched on.
The practical damage is in routing. A rep receives a lead, emails it, it bounces, and the lead sits in the queue as worked. Multiply that across a quarter and the pipeline numbers describe activity that never reached anyone.
How the data moves
Add custom fields to Lead and Contact both
A picklist for the verdict and a date for the check, on each object. Map them in the conversion mapping so a converted Lead carries its verdict across.
Verify through the API, a file upload or Zapier
For a scheduled run, query records where the verdict date is null or older than your threshold, batch them out, and write the results back. Bulk API for the write, because row-by-row updates will hit governor limits. For a one-off clean, export the report to CSV, upload it, and import the results file. For new records, a Zapier step checks each address as it arrives.
Use the verdict in assignment rules
Route confirmed addresses to email cadences and unresolvable ones to a phone-first queue. Every lead still gets worked, on the channel that reaches it.
Report on the verdict, not on activity
A report grouping leads by verdict shows how much of the pipeline was never contactable, which is usually the first time anyone has seen that number.
Setting it up
- Create a picklist field for the verdict and a date field for the check on both Lead and Contact.
- Add both to the Lead-to-Contact conversion field mapping so the verdict survives conversion.
- Build a scheduled job that batches unverified records out and writes results back through the Bulk API.
- Add the verdict to lead assignment rules so unresolvable addresses route to a calling queue.
- Create a report grouping open leads by verdict and share it with sales management.
- Switch on Salesforce bounce management so its own bounce fields populate alongside yours.
Salesforce: common questions
Lead or Contact first?
Leads, because that is where the untested addresses are. Contacts have usually been emailed successfully at least once.
Apex or middleware?
Middleware if you already run one, because the retry and backoff logic is easier outside Apex. Scheduled Apex works for moderate volumes.
What happens to duplicate addresses?
Duplicates in a batch are collapsed before billing, so the same address is charged once. Merge duplicate Lead and Contact records in Salesforce first, so each person carries one verdict.
Can I connect Salesforce without writing Apex?
Yes. Use Zapier to check each new Lead or Contact, or export a report to CSV, upload it for bulk verification, and import the results file back with the verdict column mapped to your custom field.
Check a Salesforce export today
100 free checks a month, no card. Unknown results are refunded.