Apollo.io + Salesforce Integration Guide: Full Setup 2026

The Apollo.io and Salesforce integration is the backbone of most outbound operations that have grown past the spreadsheet stage. The setup is straightforward in theory and full of small landmines in practice. Wrong sync direction, undefined dedup rules, and untested mappings can leak hundreds of contacts a month or worse, corrupt your CRM data over time. This guide is the playbook we use when we configure this integration for clients running production outbound.

We have set up this integration for SaaS, professional services, and B2B clients across multiple industries. The notes below cover what the official docs skip and what production usage actually requires.

Why This Integration Matters

Apollo.io is your data and outbound layer. Salesforce is your CRM and revenue system of record. Integrating them well means SDR activity flows into the CRM cleanly, sales reps see Apollo enrichment data on Salesforce records, and dedup logic prevents your data from becoming a mess.

Integrating them poorly means duplicate records, missing activity, lost ownership data, and a CRM that nobody trusts. We have audited several Salesforce instances where the Apollo integration was the root cause of data quality issues that took months to clean up.

The setup steps below take 30 to 60 minutes if you have admin access to both tools. The decisions you make during setup matter for years.

Step 1: Decide the Source of Truth

The first decision is which system owns your contact data.

For most teams, Salesforce should be the source of truth. Salesforce holds account hierarchy, deal data, and historical context that Apollo cannot match. Apollo enriches Salesforce records with current data and surfaces new contacts at known accounts.

The exception is teams running Apollo as their primary outbound platform with no Salesforce SDR usage. These teams sometimes prefer Apollo as the source for new contacts, with sync to Salesforce only when contacts qualify into pipeline. This works but requires tighter sync rules.

The decision shapes every other configuration choice. Make it explicitly before you connect the integration.

Step 2: Set Up Apollo's Salesforce Connection

In Apollo:

1. Navigate to Integrations and select Salesforce. 2. Authenticate with a Salesforce admin account that has API access enabled. 3. Apollo will pull standard objects (Account, Contact, Lead, Opportunity, Task) by default. 4. Map custom fields if you have them. Common custom fields to map: Lead Source, Lifecycle Stage, MQL/SQL flags, ICP score. 5. Configure sync direction per object. Most setups push Apollo activity into Salesforce and pull Salesforce contacts/accounts into Apollo.

Apollo's default mapping covers the basics. Custom fields require explicit mapping or they are ignored.

Step 3: Configure Dedup Rules

This is the step most teams skip and regret later.

Apollo's default contact dedup uses email address as the primary key. This works most of the time but creates problems when:

- A contact changes companies and gets a new email address (Apollo creates a duplicate) - A contact has multiple aliased email addresses on record (Apollo creates duplicates) - Salesforce has stale or test contacts with no email (Apollo skips them entirely)

Configure stricter dedup logic:

1. Use email as primary match. 2. Add a fallback match on first name + last name + LinkedIn URL. 3. Set up Apollo to update existing records rather than create new ones when a near-match is detected. 4. Run a one-time dedup audit before the first sync to clean up existing duplicates.

Without these rules, the first sync will likely create 5 to 15% duplicate records in Salesforce.

Step 4: Define What Syncs Each Direction

By default, Apollo will sync everything. This is rarely what you want. Define explicit rules.

Salesforce to Apollo (pull):

- Accounts that match your ICP filter - Contacts associated with those accounts - Open opportunities (so reps see deal context in Apollo) - Activity history for context

Apollo to Salesforce (push):

- Activity records (emails sent, opens, replies, calls, meetings booked) - New contacts only when they meet a qualification trigger (replied, booked meeting, opened multiple times) - Enrichment updates to existing records (with explicit field mapping)

The big rule: do not push every Apollo contact into Salesforce. The volume creates noise, and most contacts in an Apollo sequence are not worth a Salesforce record.

Step 5: Map Custom Fields Correctly

If your Salesforce instance uses custom fields (and most do), Apollo needs explicit mapping.

Common mappings to configure:

Get these mappings reviewed by whoever owns Salesforce data quality. The wrong mapping can pollute fields used in dashboards, automations, or reporting.

Step 6: Configure Activity Sync

Activity records are where Apollo most directly impacts Salesforce data.

The recommended config:

- Email sent: log as Task with type "Email - Outbound" - Email opened: log as event timestamp on the contact, not as a Task - Email reply: log as Task with type "Email - Inbound" and update Last Activity - Call logged: log as Task with type "Call" - Meeting booked: log as Event and update opportunity stage if relevant

Logging every email open as a separate Task is overkill and floods the activity timeline. Aggregate opens into a daily summary or skip them entirely.

Step 7: Test the Sync With a Small Sample

Before turning on full sync:

1. Create a test list in Apollo with 50 contacts, including some that exist in Salesforce, some that do not, and some near-duplicates. 2. Trigger a sync and watch what happens. 3. Verify dedup behavior, field mapping, activity logging, and ownership assignment. 4. Fix any issues before scaling.

Most configuration mistakes show up in this test phase. Catching them with 50 records is much easier than catching them after 5,000 records have flowed through.

Step 8: Set Up Ownership Rules

A sync that creates Salesforce contacts without proper owner assignment leaves contacts unassigned and outside any workflow.

Configure ownership:

1. Default new contacts to the Apollo user who initiated the sequence. 2. For Salesforce-sourced contacts, preserve the existing Salesforce owner. 3. Set up a fallback owner for edge cases (typically the head of SDR or a system user). 4. Audit owner assignment monthly.

Without explicit rules, Apollo will assign all synced contacts to the integration user, which is rarely what you want.

Step 9: Audit Sync Weekly During First 90 Days

The integration is rarely perfect on day one. Configuration drift, edge cases, and sync errors surface over time.

Weekly checks:

- Apollo records that did not sync to Salesforce despite meeting trigger criteria - Salesforce records that did not enrich from Apollo despite matches existing - Duplicate detection: pull Salesforce contacts created in the last 7 days and check for duplicates - Activity logging: spot-check 10 sequences and verify activity flowed correctly

After 90 days, monthly audits are usually sufficient.

Common Pitfalls

Five issues show up repeatedly when we audit existing Apollo + Salesforce setups.

Duplicate contact creation. Almost always traces back to weak dedup rules or incomplete email field mapping.

Missing activity records. Usually a permissions issue: the Apollo user does not have write access to the Activity object or to specific custom fields.

Stale enrichment data. Apollo can be configured to update or to leave fields unchanged. Most teams want updates on title, company, and phone, but not on owner or lifecycle stage.

Test environment contamination. Apollo connecting to a Salesforce sandbox accidentally syncs production data into the sandbox. Always verify which Salesforce instance you are connecting to.

Permission scope too broad. Apollo gets full admin access by default, which is more than it needs and creates security risk. Scope down to the specific objects and fields it needs to read and write.

When This Integration Is Worth Outsourcing

For teams running serious outbound, the Apollo to Salesforce integration is mission-critical. Errors propagate fast and cleanups are expensive. Many teams underestimate how much ongoing operations time this takes.

This is part of what we run for clients as part of our managed outbound service. We configure the integration, monitor it, and maintain it as Apollo and Salesforce update. Clients keep ownership of the configuration; we keep it healthy.

For more on the managed approach, see our services or case studies. For broader context on the Apollo stack, our Apollo to Instantly integration guide covers the sending side.

Ready for an Apollo + Salesforce Stack That Just Works?

We build and run the full outbound stack, including the Apollo to Salesforce integration, for clients. You get the data quality and the meetings without the integration headache.

Book your free pilot →