Your sales team just spent three hours prospecting in Apollo. Then someone forgot to log it in Salesforce. Now your AE has no idea a hot lead exists.
This happens every single day in teams that haven't connected these two tools properly.
The good news? Fixing it isn't complicated. It just requires doing it in the right order, with the right settings, so your CRM stays clean instead of turning into a duplicate-filled mess six months from now.
Here's everything you need to connect Apollo.io to Salesforce the right way, whether you're setting this up for the first time or fixing a sync that's already gone sideways.
Key Takeaway
The Apollo.io Salesforce integration syncs leads, contacts, accounts, and opportunities between both platforms in real time. Set it up with a dedicated integration user, clear field-ownership rules, and defined sync direction, and your reps get enriched CRM data without the duplicate-record chaos that sloppy setups create.
Why Connect Apollo.io to Salesforce in the First Place
Let's start with the actual problem this solves.
Apollo is where your team finds prospects. It's packed with verified emails, direct phone numbers, and firmographic data that make outbound actually work.
Salesforce is where your revenue lives. Every deal, every stage, every dollar of pipeline gets tracked there.
Without a connection between them, your reps are stuck doing one of two frustrating things:
- Manually copying leads from Apollo into Salesforce, one record at a time
- Working in Apollo and hoping someone remembers to update the CRM later
Neither of those scales. And both of them lead to reps working stale data, AEs missing context on warm leads, and managers pulling pipeline reports that don't match reality.
The integration fixes this by keeping records aligned automatically. Once it's connected, Apollo pulls existing Salesforce data in so reps aren't duplicating work on people already in the CRM. And depending on your settings, Apollo can push contacts, leads, accounts, deals, and activity — emails, calls, notes, meetings, even AI-generated conversation summaries — straight back into Salesforce.
That means your AE opens a Salesforce record and actually sees what happened in Apollo. No more asking the SDR to "walk me through what you've sent this person."
What You Need Before You Start
Don't skip this part. Missing even one of these prerequisites is the number one reason setups stall out halfway through.
You'll need:
- An Apollo.io plan that includes CRM integrations — check your current plan under Apollo's Salesforce integration overview if you're unsure what's included
- Salesforce admin access, or at minimum, a Salesforce user with API access enabled
- Permission to edit CRM integrations inside Apollo itself
- A Salesforce edition that supports API access — this typically means Enterprise, Unlimited, or Performance editions; Essentials and some Professional editions may not qualify without an add-on
- About 30 to 60 minutes of uninterrupted setup time if you already have admin access to both platforms
One more thing before you touch any settings: decide who "owns" your contact data.
This sounds like a small decision. It isn't. Getting this wrong is the single biggest cause of the duplicate-record disasters teams complain about months later.
Step 1: Set Up a Dedicated Salesforce Integration User
Here's a mistake almost everyone makes on their first attempt: connecting the integration using someone's personal Salesforce login.
Don't do that.
Apollo specifically recommends connecting the integration through a dedicated integration user rather than an individual's account. There's a real reason for this:
- Personal accounts get deactivated when employees leave, which can break your entire sync overnight
- Password resets and MFA changes on a personal login can silently disconnect the integration
- A dedicated user makes the connection stable and far easier to manage long-term
- It gives you a clean audit trail of what the integration is doing versus what a human rep did manually
Create a dedicated Salesforce user specifically for this integration. Give it API access and the permission sets it needs to read and write to leads, contacts, accounts, and opportunities.
This single step will save you a support ticket six months from now when "the sync randomly stopped working."
Step 2: Connect Apollo to Salesforce
Now for the actual connection.
Inside Apollo:
- Log into your Apollo.io account
- Click Settings, then select Integrations
- Find and select Salesforce
- Click Yes, Continue to proceed with the connection
- Sign in using the dedicated Salesforce integration user you just created
- Authorize Apollo's managed package to access your Salesforce org
Apollo uses a managed package plus OAuth authorization for this connection. That means you're not manually configuring webhooks or writing custom API code. The standard integration is native and bidirectional right out of the box.
Once you authorize the connection, Apollo and Salesforce are talking to each other. But don't stop here. The default settings are rarely what your team actually needs.
Step 3: Choose Your Sync Direction (This Is the Part People Rush)
This is where most integration headaches actually start.
Apollo's Salesforce sync runs in two directions, and you control both independently:
Pull: Brings existing Salesforce records into Apollo on a recurring basis. This lets your reps work with real CRM data while they're prospecting, so they're not accidentally reaching out to someone who's already a customer or already in an active deal.
Push: Sends Apollo records and activity into Salesforce whenever your push settings and sync rules are met. This can include:
- New contacts and leads found in Apollo
- Updated account information
- Deals created or advanced in Apollo
- Emails, calls, notes, tasks, meetings, and conversation summaries
Here's the question you actually need to answer before enabling either direction: which system owns your contact data?
For most sales teams, Salesforce should be the system of record. That means:
- Salesforce field values take priority when there's a conflict
- Apollo enrichment fills in gaps but doesn't overwrite fields Salesforce already controls
- New records created in Apollo push into Salesforce, but existing Salesforce data stays protected
Get this backwards, and Apollo's enrichment can start overwriting values your revenue operations team has spent months cleaning up. That's exactly the kind of "data quality issue that took months to clean up" that RevOps teams end up auditing after a rushed setup.
Step 4: Map Your Fields Correctly
Field mapping is the unglamorous part of this setup. It's also where duplicate and mismatched data quietly creeps in if you skip it.
Go through your field mappings deliberately:
- Match Apollo's standard fields (email, phone, title, company, industry) to their Salesforce equivalents
- Decide what happens with custom fields your Salesforce org already uses
- Set mapping rules for lead source, so Apollo-sourced leads are clearly tagged as such in reporting
- Confirm how Apollo handles Salesforce's Lead vs. Contact distinction, since this trips up a lot of first-time setups
Don't just accept every default mapping without reviewing it. Five extra minutes here prevents hours of cleanup later.
Step 5: Configure Duplicate Handling and Sync Rules
This is the step that separates a clean integration from the ones that turn into a support nightmare.
Set clear rules for:
- Deduplication: How Apollo matches existing Salesforce records so it doesn't create a second copy of someone already in your CRM
- Do-not-contact respect: Contacts marked as do-not-email or opted out in Salesforce should be respected across your outbound tools, not just quietly ignored
- Sync frequency: How often data pulls and pushes actually run
- Record ownership: Who gets assigned as the owner when Apollo creates a new Salesforce record
A loose integration here really is worse than no integration at all. Teams that rush this step often celebrate that the sync is "live," then spend the next quarter untangling duplicate contacts and explaining to sales leadership why pipeline reports don't match actual rep activity.
Step 6: Test With a Small Batch Before Going Live
Don't flip the switch for your entire database on day one.
Instead:
- Push a small batch of test contacts, maybe 10 to 20, and watch how they land in Salesforce
- Check that field values mapped the way you expected
- Confirm duplicate detection actually caught existing records instead of creating copies
- Verify activity logging (emails, calls, notes) is showing up correctly on the right records
If something looks off, you want to catch it with 20 test records, not 2,000 real ones.
What Reps and Managers Actually Get Once It's Running
Once this is dialed in correctly, here's what changes day to day:
- AEs open a Salesforce record and immediately see the Apollo enrichment data, engagement history, and sequence activity for that contact
- Reps no longer manually re-enter leads they already found in Apollo
- Managers get pipeline reports that actually reflect what's happening in outbound, not a partial picture with gaps
- New contacts found through Apollo prospecting flow into Salesforce automatically, tagged with the right lead source
- Nobody's guessing whether a prospect has already been contacted, because activity is visible in one place
That last point matters more than people expect. The handoff failure between SDR and AE is rarely a rep performance problem. It's usually a systems problem, and this integration is one of the more direct fixes for it.
Common Mistakes That Break This Integration
A few patterns show up again and again in setups that go wrong:
- Using a personal login instead of a dedicated integration user, which breaks the sync the moment that person changes their password or leaves the company
- Enabling push in both directions without defining field ownership, which leads to fields silently overwriting each other
- Skipping the deduplication settings, which floods Salesforce with duplicate leads and contacts within weeks
- Never testing with a small batch first, discovering the problem only after thousands of records are already affected
- Ignoring do-not-contact flags across systems, creating real compliance risk when someone marked opted-out in Salesforce keeps getting emailed through Apollo
Every one of these is preventable. None of them require advanced technical skill to avoid. They just require slowing down during setup instead of racing to mark the integration "done."
Apollo.io Salesforce Integration vs. Manual Data Entry
|
Factor |
Apollo-Salesforce
Integration |
Manual
Entry |
|
Time
per lead |
Automatic,
near-instant |
Several
minutes per record |
|
Duplicate risk |
Low, with dedup rules configured |
High, especially at scale |
|
Data
freshness |
Continuously
synced |
Only as
current as the last update |
|
Activity visibility |
Logged automatically across both tools |
Depends on rep discipline |
|
Setup
effort |
30–60
minutes, one time |
None,
but ongoing time cost forever |
|
Scalability |
Scales with team growth |
Breaks down past a handful of reps |
The upfront setup time is the only real cost. Everything else favors the integration once it's live.
FAQs
Does Apollo.io have a native Salesforce integration, or do I need a third-party tool?
Apollo provides a native, bidirectional Salesforce integration. It supports syncing leads, contacts, accounts, opportunities, and selected activities without requiring middleware, using an OAuth-authorized connection through Apollo's managed package.
Can I control which direction data syncs?
Yes. You can configure pull settings, push settings, or both, independently. This lets you decide whether Apollo only enriches from Salesforce, only pushes new activity into Salesforce, or does both at once.
What Salesforce permissions do I need to set this up?
You need permission to edit CRM integrations inside Apollo, plus a Salesforce account with API access enabled. Apollo recommends using a dedicated integration user rather than a personal login for stability.
Will this create duplicate records in Salesforce?
Not if your deduplication and sync rules are configured properly during setup. Duplicates typically happen when teams skip this configuration step or don't test with a small batch before rolling out to the full database.
Does the integration respect do-not-contact settings?
Yes, when configured correctly. Contacts marked as do-not-email or opted out in Salesforce should be respected across the connected tools, which matters both for data hygiene and outbound compliance.
How long does setup actually take?
If you already have admin access to both Apollo and Salesforce, budget 30 to 60 minutes for a careful setup. Rushing it to save 20 minutes is exactly how the duplicate-data problems described above start.
Final Thoughts
The Apollo.io Salesforce integration isn't complicated to set up. It's complicated to set up well, and that distinction matters more than most guides admit.
A rushed connection gets you a sync that's technically live but quietly corrupts your CRM over the following months. A deliberate setup, done in the order above, gets you a system your whole revenue team can actually trust.
Take the extra 30 minutes. Use a dedicated integration user. Define who owns your data before you flip on bidirectional sync. Test with a small batch first.
If you're still evaluating whether Apollo.io fits your outbound stack before committing to the integration work, you can [try Apollo.io here](Apollo.io affiliate link) and see how the prospecting and enrichment side performs before connecting it to your CRM.