Almost every broken CRM integration I have seen broke the same way. Someone turned on a connector, chose "two way sync" because it sounded more complete than one way, and six weeks later the account record for a target company had four contacts who were the same person, an owner field that changed overnight, and a timeline containing eleven hundred profile view events.
None of that is a sync bug. It is a design decision nobody made. Sync direction is not a technical setting, it is a statement about which system is allowed to be wrong. The CRM owns commercial truth: who owns the account, what stage the deal is in, who must not be contacted. The outreach layer owns what happened on LinkedIn: who was contacted, who accepted, who replied. Once you write that split down, most of the classic failures stop being possible.
What a CRM integration actually has to do
A CRM integration has exactly three jobs: put newly qualified people into the CRM without creating duplicates, put outreach outcomes onto the right record so a rep can read them at a glance, and pull commercial context back out so nobody contacts a customer by mistake. Everything else a connector advertises is optional.
Notice that two of those three jobs run in opposite directions. That is the whole point. A connector configured as a symmetric two way pipe cannot do job one and job three at the same time, because job three requires the CRM to win every conflict and job one requires it to accept records it has never seen. Direction has to be set per object, not per integration.
The sync matrix: object, direction, and what breaks
Set direction per object, not per integration. People, companies, connection status and outreach outcomes flow from LinkedIn into the CRM. Ownership, lifecycle stage and suppression flow the other way and are never written back. Write the direction down once per object, then make the connector enforce it rather than trusting a default.
| Object | Direction | Rule | What breaks if you get it wrong |
|---|---|---|---|
| Person / contact | LinkedIn to CRM, one way | Create only after qualification, match before create | The same human exists three times, under three owners, receiving three sequences |
| Company / account | LinkedIn to CRM, one way | Match to an existing account first, create only if no match | Orphan accounts, and contacts attached to a company record with no deals or history |
| Connection status | LinkedIn to CRM, one way, read only in CRM | Mirror pending, accepted, connected | Reps re-invite people they are already connected to, spending an invitation budget that LinkedIn limits |
| Message thread | LinkedIn to CRM, one way | Log that a reply happened plus a short excerpt, not the full transcript | A reply lands, nobody sees it, and the follow up sends anyway |
| Outreach activity | LinkedIn to CRM, filtered | Milestones only, never every action | The timeline drowns and the team stops reading it, which costs you the replies buried in it |
| Record owner | CRM to LinkedIn, one way | The CRM is the only writer, always | Two reps work the same account, or an owner is silently reassigned by a tool |
| Lifecycle or deal stage | CRM to LinkedIn, one way | Read it before sending, never write it from outreach | Prospecting messages go to a live opportunity, or to a closed won customer |
| Suppression list | CRM to LinkedIn, one way, blocking | Resolve before the send, not after | The worst one: a cold pitch to an existing customer, forwarded to your account manager |
| Current employer | LinkedIn to CRM, additive only | Create a new contact on job change, never overwrite | The history of who you sold to is silently rewritten, and closed deals detach from their buyer |
| Email, phone, firmographics | Write once into empty fields only | Never overwrite a populated field | Verified CRM data is replaced by weaker public data, and nobody notices for a quarter |
Two rows carry most of the value. "Record owner: CRM to LinkedIn, one way" prevents the political failure, the one that ends with a rep in your manager's office. "Suppression list, blocking" prevents the commercial failure, the one that ends with a customer asking why you are selling them software they already pay for.
Where the sync should live
Four places the sync can run, and the choice is mostly a budget and control decision. Native Sales Navigator sync sits in a tier LinkedIn does not price publicly. An outreach tool's own connector gives you direction control. Middleware gives you the most control and the most maintenance. A scheduled export is underrated.
| Where the sync runs | What it costs | Direction control | Main failure mode |
|---|---|---|---|
| Sales Navigator Advanced Plus, native CRM sync | Not published by LinkedIn. Quoted on team size, CRM and onboarding | Preset by LinkedIn, little field-level choice | You pay per seat for the tier and the sync still knows nothing about your suppression rules |
| Your outreach tool's own connector | Included in the outreach subscription. BeReach Pro is EUR 99 per month billed monthly, or EUR 948 per year, per workspace rather than per seat | Per object, if the tool exposes it | Defaults are usually "sync everything", so you inherit the noise unless you turn it down |
| Middleware or iPaaS | Per task or per operation, on top of both subscriptions | Total, field by field | Highest control and highest maintenance. It becomes a system nobody owns once the person who built it leaves |
| Scheduled export into the CRM importer | Effectively free | Manual, and one way by construction | No live suppression check, so it only suits low volume |
The honest read on row one: native platform sync is the only option that cannot enforce your commercial rules, because LinkedIn does not know which of your accounts are customers. Rows two and three can. That is a bigger difference than any feature checklist suggests.
The numbers on the ranking pages that do not survive checking
Two figures dominate other write-ups, and neither holds up. One turns a marketer adoption survey into a lead attribution claim. The other prints a price LinkedIn has never published. Both are easy to check at the source, and checking them changes what you decide to buy.
"LinkedIn drives 89% of all B2B leads." The page usually cited for this is LinkedIn's own social selling page, and it says something different: "89% of B2B marketers use LinkedIn to generate leads" (LinkedIn Sales Solutions, social selling page, checked August 2026). That is adoption, not attribution. It tells you how many marketers turned up, not how much pipeline arrived. Using it to justify integration spend is a category error.
"Sales Navigator Advanced Plus, $1,600 or more per year." Advanced Plus is the tier that carries native CRM sync, and LinkedIn does not publish a price for it anywhere. The compare-plans page lists two tiers with public prices: Core at $119.99 per month billed monthly, or $1,079.88 per year billed annually, about $89.99 per month; and Advanced at $159.99 per month billed monthly, or $1,799.88 per year billed annually, about $149.99 per month. Advanced Plus is quoted by sales (LinkedIn compare-plans page, checked October 2026). Advanced Plus is quoted privately by the sales team, priced on team size and CRM integration.
The "$1,600" number is a third-party estimate of a per-seat cost, and the problem is not the estimate, it is the presentation. At least one widely cited comparison page prints it in seven identical table rows, once per CRM, formatted exactly like the vendor prices sitting next to it. Budget from that and you are budgeting from a figure LinkedIn has never confirmed and will not quote until you talk to sales. The practical move is to price the two published tiers, then treat Advanced Plus as an unknown you get quoted rather than a line you can plan.
A third number worth handling carefully
The weekly invitation ceiling of roughly 100 is industry consensus, not published policy. LinkedIn does not state a figure anywhere, so any page citing the LinkedIn Help Center for "100 invitations per week" is citing a source that does not contain it. Treat it as a well-supported community estimate and plan below it, which is what the pacing rules further down assume.
Duplicates are a matching problem, not a sync problem
A duplicate appears when the connector cannot answer "have I seen this person before" and defaults to creating. The fix is never in the sync settings. It is in the match key, the order you try keys in, and what the connector does when a lookup fails rather than returns nothing.
The awkward truth is that LinkedIn and your CRM have almost no key in common. The CRM is keyed on work email. A public profile does not carry one. So the only durable join is the member's own identity on the platform, and even the visible profile URL is not perfectly stable, because people change their vanity URL. If your connector stores the vanity slug as the key, everyone who rebrands their profile becomes a new contact tomorrow.
A matching order that survives contact with reality:
- Stored member identifier. If you have contacted this person before through the same tool, you already hold a stable handle. Trust it above everything.
- Verified email, normalised. Lowercase, strip plus addressing, ignore the display name. Only match on emails your CRM marked as verified, because an inferred pattern guess is not an identity.
- Profile URL, normalised. Strip query strings and trailing slashes. Good as a secondary confirmation, weak as a primary key.
- Name plus current company. Never auto merge on this. Flag it, show both records to a human, let them decide.
Then add the rule that saves you more work than all four steps combined: do not create the CRM record at the moment of discovery. Create it at the moment of qualification. If you push every profile a search returned into the CRM, you have imported a browsing session, not a pipeline. This lines up naturally with how BeReach works: it builds the prospect list from public data and drafts a first message per person, all before a human reviews and approves it. The CRM write can therefore sit at the qualification boundary, after fit is decided and before anything is sent.
Creating late is also the cheapest privacy posture available: every profile you never wrote is a record you never have to justify, minimise or delete. For the same reason, run exploratory searching outside the CRM entirely. A free people search is the right place to find out whether a segment even exists. The CRM is for people you have decided to work.
Less searching.
More conversations.
Tell Vera who you want to reach. Review the first message. Take it from there.
Ask Vera to find leads
Rate limits are why the first import is the dangerous one
Steady-state syncing almost never exhausts a CRM API quota. The first bulk import does, because it fires thousands of lookups in a few minutes and burst limits are much tighter than daily ones. That is also when duplicates are created, since a rate-limited lookup can be misread as "no match found".
Here are the actual ceilings, from the vendors rather than from summaries of them:
- Salesforce. Enterprise and Professional editions get 100,000 API calls per 24 hours plus 1,000 per Salesforce license. Developer Edition is fixed at 15,000 (Salesforce developer documentation, API request limits and allocations, checked August 2026).
- HubSpot. Private apps get 190 requests per 10 seconds on Professional and Enterprise, and 100 per 10 seconds on Free and Starter. Daily ceilings are 625,000 on Professional and 1,000,000 on Enterprise, shared across all apps in the account (HubSpot developer documentation, API usage guidelines, checked August 2026).
Now the arithmetic that matters. A single sender working through BeReach can visit up to 300 profiles a day at base pacing, held under 120 an hour, alongside about 20 connection invitations a working day (paced at least 180 seconds apart, with no fixed cap, planned at about 100 a week because LinkedIn's own limit is what stops them) and up to 70 messages a day at base. Profile visits and messages are base figures that a workspace multiplier scales, so a busier workspace runs higher; the 120 visits an hour is the unconditional ceiling.
Take the base case: about 390 actions per sender per day. Five senders is about 1,950 actions, and even at two API calls each that is about 3,900 calls against a Salesforce Enterprise org with five licenses, which is allocated 105,000 per 24 hours. Four percent. The daily quota is not your problem and never was.
The burst window is. HubSpot's 190 requests per 10 seconds is 19 per second. A first import of 5,000 qualified profiles, at two calls each for a lookup and a create, is 10,000 calls, which needs about nine minutes of perfectly paced traffic and returns HTTP 429 immediately if it is not paced. So the rule that connects this section to the previous one:
A failed lookup must never be read as a negative answer.
A rate-limited lookup and an empty lookup look identical to careless code, and only one of them means "create". Retry with backoff, and if the retry budget runs out, queue the record for a human rather than inserting it. That single branch is the difference between a clean import and 5,000 half-matched contacts. It is also exactly the rule suppression needs, for exactly the same reason.
Owners: the CRM wins, and it is not close
Ownership is the one field where a wrong write costs trust rather than data. Let the CRM be the only system that can set it. Outreach tooling reads the owner to decide who signs a message and who receives the reply, and writes nothing back. If a contact arrives with no owner, stop and ask.
The failure mode here is subtle because it usually looks like a feature. A connector offers to "assign new leads to the connecting user", which is reasonable for genuinely new names and catastrophic when the matcher mis-fires on an existing account. One bad match and a strategic account changes hands in an audit log nobody reads. Make ownership writes impossible rather than discouraged, then the question never comes up.
Territory rules are the same shape. Whether an account belongs to enterprise or mid market is a CRM decision that outreach reads and obeys. If you run named account plays, the account-based approach already assumes the target list is defined in the CRM, so the outreach layer is downstream by design.
Activity noise: log the four events that change a decision
Log what changes someone's next action and nothing else: invitation sent, invitation accepted, first message sent, reply received. Four rows per contact across an entire sequence. Profile views, retries and intermediate states stay in the outreach tool, where they remain queryable but never compete for space on the account timeline.
The arithmetic from the previous section applies again, in a different currency. Those same 390 or so actions a day per sender are cheap in API calls and ruinous in attention. Multiply by a team and the account history becomes unreadable within a week. An AE opening the account before a call needs to see "replied on 4 September" in the first screenful, not scroll past a wall of view events to find it. Four milestones per contact compresses that to something a human reads in two seconds.
There is a second reason to filter, and it is about how the numbers get read later. Reply rate is only meaningful against a clean denominator. Belkins' 2026 study of 15.1 million touchpoints put LinkedIn replies at 7.9% on a cold connect then message sequence, and 12.2% when messaging someone already connected. Expandi's 2026 benchmark, drawn from 13.2 million outreach attempts, put the LinkedIn platform average message reply rate at 10.4%. Belkins has since restated its cold email benchmark at 0.45% on 7.5 million 2025 sends, measured against total sends rather than opens.
You can only compare your own numbers to any of those if your CRM counts "messages sent" the way the studies did. If your activity log conflates views, invitations and messages into one undifferentiated stream of "LinkedIn activity", you cannot compute either figure, and every dashboard built on top of it is decorative. Deciding which outreach metrics actually matter is a schema decision you make here, not a reporting decision you make later.
The same discipline decides which parts of the workflow are worth wiring together at all. Our take on what to automate and what to keep manual applies directly: sync the outcomes, keep the judgement.
Job changes are the one update that must not overwrite
When a contact changes employer, the instinct is to update the company field. Do not. That silently rewrites history, detaches the contact from the account holding the closed deals, and destroys the record of who you actually sold to. Create a new contact at the new company and mark the old record as departed.
This is the one place where the "never overwrite a populated field" rule needs to be stated as something stronger than a preference, because job change data is the single most valuable thing a LinkedIn integration can bring back and the single easiest thing to apply destructively. A champion who moves from a customer to a prospect is the warmest lead in your database. Overwrite the old record and you get a contact who appears to work somewhere they never bought anything, attached to an account whose renewal now has no known contact.
The additive version costs one extra record and buys two assets: a live lead at the new employer, and an accurate gap in the old account that tells the CSM to go find a new champion. If you act on job change signals at all, the write policy is what determines whether they compound or corrode.
Suppression is the sync that runs before the send
This is the only sync with a hard ordering requirement. Every other field can reconcile on a schedule. Suppression has to resolve before the message leaves, because there is no undo. Pull four lists from the CRM: existing customers, contacts on open opportunities, explicit do-not-contact flags, and anyone owned by another rep running a different play.
A nightly batch is not good enough here, and the reason is timing rather than laziness. Deals move during the working day. A prospect who signs at 11am is a customer at 11:01, and your 2pm send is going out to a customer if suppression last refreshed at midnight. Check at send time against live CRM state, apply the same failed-lookup rule from the import section, and treat a 429 or a timeout as a block rather than a pass. Delaying a message costs you nothing. Sending the wrong one costs you the account.
This is also the argument for keeping a human at the send boundary rather than only at the configuration boundary. Every BeReach message is approved by a person before it goes out, which means the suppression check has a second reader who knows the account, and the two failure modes have to line up before a bad message escapes.
Bottom line: three integration points, not a mesh
Sequence by ownership. Suppression and ownership read out of the CRM continuously, because they gate sends. Qualified contacts write in at the moment of qualification, one record per human. Outcomes write back as they happen, four milestones deep. Nothing else moves in either direction, in either system.
That leaves three integration points instead of a mesh, which matters because every additional synced field is a field two systems can disagree about. When something looks wrong later, three points are diagnosable. A symmetric mirror of forty fields is not.
Before wiring any of it, it is worth knowing what the outreach half is actually worth, because integration effort should be proportional to pipeline. If the answer is two meetings a month, a scheduled export is a perfectly good integration. If it is twenty, the matching rules above start earning their keep.
Frequently asked questions
Should LinkedIn outreach data sync two ways with my CRM?
Not as a single symmetric pipe. Set direction per object instead. Contacts, companies, connection status and outreach outcomes flow into the CRM. Ownership, deal stage and suppression flow out of it and are never written back. The result is technically two way at the integration level, but every individual field has exactly one system allowed to write it, which is what prevents conflicts.
How do I stop LinkedIn outreach creating duplicate CRM contacts?
Fix the match key rather than the sync settings. Try a stored member identifier first, then a verified and normalised email, then a normalised profile URL. Treat a name plus company match as something a human confirms, never an automatic merge. Then create records at qualification rather than at discovery, and never let a failed lookup fall through to "create", because a rate-limited response and an empty result look identical to careless code.
Will syncing LinkedIn activity hit my CRM API limits?
Rarely in steady state, often on the first import. Salesforce Enterprise and Professional allocate 100,000 calls per 24 hours plus 1,000 per license, and HubSpot Professional and Enterprise allow 190 requests per 10 seconds per private app (vendor developer documentation, checked August 2026). Five senders at full pace use a few percent of a daily quota. A one-off import of thousands of profiles blows the ten second burst window immediately, so pace the backfill and retry on HTTP 429.
Which LinkedIn activities should actually be logged in the CRM?
Four per contact: invitation sent, invitation accepted, first message sent, reply received. Those are the events that change what someone does next. Profile views, retries and intermediate states stay in the outreach tool. One sender can generate several hundred actions a day, so logging everything makes the account timeline unreadable within a week and destroys the clean denominator you need to compare your reply rate against any published benchmark.
How often should the CRM suppression list refresh?
At send time, not on a nightly schedule. Deals close during the working day, so a prospect can become a customer hours before your afternoon send goes out. Check live CRM state immediately before sending and treat a failed lookup as a block rather than a pass. A delayed message costs nothing. A cold pitch to an existing customer costs the relationship.
