Migrate from Salesforce Service Cloud to Intercom

Salesforce Cases map to Intercom Conversations. Case Number becomes a custom 'Legacy Case ID' attribute on the Conversation for cross-reference. Case Status maps to Conversation State (open, closed, snoozed); case priority maps to a custom priority attribute. The Case Origin (Email, Phone, Chat, Web) determines the initial channel assignment in Intercom. If the destination has multiple Inboxes, we map Record Type to Inbox assignment during migration. Multi-record-type orgs require separate Conversation import batches per Record Type.

Case Comments — both public (IsPublished=true) and private (IsPublished=false) — map to Intercom Conversation Parts. Public comments become user-visible conversation parts; private comments are stored as internal notes in Intercom. We preserve the comment author (Salesforce Contact or User) mapped to an Intercom User or Teammate. Comment body and HTML formatting are sanitized and stored as part.body. The created date of each comment becomes the Conversation Part timestamp, preserving the chronological thread.

Salesforce Email Messages attached to a Case become Intercom Conversation Parts on the email channel. From, To, Cc, Subject, and HTML body migrate. Inline images require URL extraction and re-attachment as publicly accessible URLs per Intercom's image hosting requirement. Attachments migrate as file attachments on the Conversation Part. We detect inbound vs outbound on EmailMessage.Incoming and set the conversation part author accordingly (customer vs agent).

Salesforce Contacts with cases attached map to Intercom Users. We resolve the Contact email as the dedupe key. Any Contact without an email address is held in a reconciliation queue and migrated as a User with an admin-generated placeholder address pending customer admin resolution. Custom contact fields migrate as custom attributes on the Intercom User. Contacts without cases migrate as Users only if specified in scope.

Salesforce Contacts that have never been associated with a Case map to Intercom Leads. This preserves the distinction between active support contacts and marketing-originated prospects without creating duplicate User records. We flag the original Contact ID as a custom attribute for future merge if the Lead becomes a User through a new conversation.

Salesforce Accounts map to Intercom Companies. Account Name becomes Company name, and the Account's domain field maps to Company domain for workspace identification. We resolve all Contacts linked to the Account and attach them as contacts within the Company record. Account hierarchy (Parent Account) is not natively represented in Intercom; we store the parent account ID as a custom attribute if the hierarchy is material to the customer's operations.

Salesforce Case Team Members with their assigned roles have no native Intercom equivalent. We store the team member role as a custom attribute on the Conversation and tag the conversation with the teammate name. If the customer requires granular case assignment visibility, we recommend Intercom's team inbox and operator rules to recreate assignment logic post-migration.

Case Milestones (First Response, Resolution Time, and custom milestones) store RemainingTime, CompletionDate, and MilestoneType. Intercom has no native milestone object. We capture the milestone name, target date, and breach status as custom conversation attributes at migration time. For active milestones, we flag the breach window so supervisors can triage. SLA rules in Intercom can be configured post-migration using these attributes as reference data.

Salesforce Entitlements define SLA terms (response time, resolution time, business hours) linked to Contacts and Accounts. Intercom has no entitlement object. We migrate entitlement name, status, and SLA terms as custom attributes on the Intercom Company and Conversation. The entitlement-to-contact linkage is preserved by tagging the Conversation with the Entitlement ID for audit trail. Customers should configure SLA rules in Intercom using the migrated entitlement data post-migration.

Salesforce Knowledge Articles (CaseArticle-linked) migrate to Intercom Articles via the Intercom REST API. There is no native migration path; we use the Articles API to create articles in batches, preserving title, body content, URL name, publishing state (Draft, Published, Archived), and category assignments. Inline images require re-hosting with publicly accessible URLs. Article collections map to Intercom Collections. Publishing state is preserved so archived source articles do not go live in Intercom unintentionally.

Salesforce Solutions (reusable knowledge entries attached to Cases) merge into Intercom Articles. Solution titles become article titles; Solution body becomes article body. We deduplicate Solutions with matching titles before import. Solutions that are not linked to any Case are imported as standalone articles in a designated 'Legacy Solutions' collection.

Salesforce Assets represent products purchased by an Account, often linked to Cases for product-specific support. We migrate Asset name, status, and install date as custom attributes on the related Intercom Company. The Asset-to-Case linkage is preserved by tagging the Conversation with the Asset name. If the customer requires product-level ticket routing, we recommend configuring Intercom rules on a custom 'product' attribute post-migration.

Salesforce Users (agents and admins) are mapped to Intercom Teammates by email match. Active Salesforce Users with Service Cloud licenses provision as Intercom Teammates; inactive Users are excluded from the Teammate migration unless they have open Cases. The customer's Intercom admin provisions the Teammates in the workspace before production migration begins. We generate an owner reconciliation report listing any Salesforce User without a matching Intercom Teammate email.

Salesforce Case History tracks field-level audit changes (old value, new value, field, date, user). Intercom's activity log is not a full field-change audit. We migrate Case History as structured custom attributes on the Conversation capturing the most recent five field changes per dimension (Status, Priority, Owner, Resolution). Full history migration is offered as a separate document for compliance purposes if the customer's regulatory requirements demand audit trail preservation.