Intercom Salesforce integration

What an Intercom to Salesforce integration actually does

Intercom is where your customers talk to you - the live chat, the product messages, the support conversations, the tickets your team works through the day. Salesforce is where the business tracks those same people as Leads, Contacts, Accounts, and Cases, and where sales and success decide what to do next. The two systems describe the same customers, and left unconnected they drift apart within a week.

An Intercom to Salesforce integration closes that gap continuously. It matches each person in Intercom to the right record in Salesforce, turns conversations and tickets into Cases or Activities against that record, and keeps tags, custom attributes, and ownership aligned so a rep opening an Account sees the support reality, and a support agent in Intercom sees the sales context. Nobody re-keys a customer from one tool into the other.

What data moves

Intercom object / event	Becomes in Salesforce	Notes
Contact (user)	Contact or Lead	Matched by email or external_id; unmatched people become Leads by your rule
Contact (lead)	Lead	Anonymous or pre-sales visitors, kept separate from known Contacts
Company	Account	Matched by domain or a shared external ID; drives Contact-to-Account linkage
Conversation	Case or Activity	Carries state, assignee, and first-response / close timestamps
Ticket	Case	Ticket type and state mapped to your Case record type and status
Tags	Case / Contact fields or topics	Agreed mapping, not a free-text dump
Custom attributes	Custom fields	Typed and mapped per object, not flattened into a notes blob
Assignee / team	Case owner / queue	Mapped from Intercom teammates to Salesforce users

The exact objects, record types, matching keys, and field mappings are agreed once and encoded in the pipeline. After that, nobody maps them again by hand.

The details that break naive syncs

A native app or a generic connector gets you most of the way and leaves the expensive edge cases on your desk:

• Identity matching. An Intercom contact and a Salesforce Contact are the same person only if you match them reliably - by verified email, by external_id, or by company domain. Match too loosely and you merge two customers; match too strictly and you create a duplicate Lead next to an existing Contact. This dedup logic is the heart of the integration, not an afterthought.
• Lead versus Contact. Salesforce splits a person into Lead before conversion and Contact after. A sync that ignores this either overwrites a converted Contact with stale Lead data or spawns a duplicate. The pipeline has to know which state a person is in and write to the right object.
• Record types and custom objects. Real Salesforce orgs have multiple Case record types, required fields, validation rules, and custom objects a generic connector never anticipates. A write that ignores a required field or a validation rule silently fails - or worse, half-succeeds.
• API limits and volume. Salesforce meters daily API calls, and a busy Intercom workspace generates a lot of events. Writing one record per call burns the allocation and throttles. Deltas, bulk batching, and back-off are the difference between a sync that scales and one that stalls at month-end.
• Conversation history. A conversation is a thread of many parts across days, not a single field. Deciding what lands in the Case - a summary, the full transcript, or a deep link back to Intercom - is a real design choice, not a default.
• Idempotency and ordering. Events arrive out of order and get redelivered. A naive sync applies a stale update after a fresh one, or creates the same Case twice. The pipeline has to key every event and apply it exactly once, in the right order.

How we build and run it

We treat this as a pipeline, not a one-off import. Intercom contact, company, conversation, and ticket events are received by webhook (or pulled on a schedule for backfills), validated, matched against Salesforce, transformed into your agreed object model, and written through the Salesforce Bulk and Composite APIs.

The pipeline is idempotent: every Intercom event carries a stable identifier, so a redelivery or a retry never produces a duplicate Lead, Contact, or Case. It runs on cloud-native, fully EU-hosted infrastructure, so contact and conversation data never leaves the EU - which keeps the DPA / AVV and your GDPR obligations clean.

And then we keep it running. Monitoring, alerting, incident response, and - critically - watching for Intercom and Salesforce API changes are our responsibility under contract. When Salesforce deprecates an API version or Intercom changes a webhook payload, that is our problem to fix, not a surprise your revenue team discovers when records stop syncing. You get a named owner and an SLA rather than a workflow somebody has to babysit.

When this integration is worth building

If one team uses both tools, your contacts are clean, and Intercom’s native Salesforce app maps to your object model without a fight, use it - and we will tell you so. The managed pipeline earns its place when identity matching gets hard, when you have duplicate contacts or multiple Salesforce record types and custom objects, when conversation and ticket volume starts eating your API allocation, or when support and sales keep arguing about which system is right because the two never quite agree. That is the point where a pipeline that dedupes, batches, and runs itself pays for itself.