Migrate from Intercom to Salesforce Service Cloud

Intercom Contacts (Users and Leads) map to Salesforce Contact. The Intercom contact email becomes the Contact email field and dedupe key. We preserve all standard Intercom contact attributes (name, phone, custom attributes) and link each Contact to a Salesforce Account resolved via the Intercom Company association. If the Intercom contact has no linked Company, we create a default Account or map to a designated placeholder Account during scoping.

Intercom Company records map to Salesforce Account. The company name becomes Account Name; website becomes Account Website; plan and monthly_spend become custom fields. We preserve the Company-Contact relationship as Account-Contact hierarchy. Account is created before Contact import so that the AccountId Lookup is satisfied at insert time.

Each Intercom Conversation maps to a Salesforce Case. The Case Subject is derived from the conversation title or first message body truncated to 255 characters. Case Status maps from the Intercom conversation state (open=Open, closed=Closed). We preserve the original Intercom conversation ID in a custom field intercom_conversation_id__c for audit and cross-reference. The case is linked to the Contact and Account resolved from the conversation's contact and company associations.

Intercom conversation Parts (messages from user, admin, note, assignment, close) map to Salesforce EmailMessage records linked to the parent Case. We sequence messages chronologically and preserve author attribution (admin vs contact), message body, attachments, and delivery metadata. Note-type Parts migrate as internal Case Comments. We pull this data via the Intercom REST API retrieve-conversation endpoint rather than S3 JSON export because transcripts are excluded from the S3 export.

Intercom Articles migrate to Salesforce Knowledge Base Articles. Article title, body (rich text), author, publication state, and collection mapping transfer. Public URL redirection requires manual configuration post-migration because Salesforce generates different article URLs. Collection hierarchy maps to Salesforce Data Category Groups and Categories if the customer uses category-based visibility rules.

Intercom Tags migrate as Salesforce Topics linked via TopicAssignment records, or as a custom multi-select picklist on Case depending on customer preference during scoping. Tag strategy is a scoping decision because Salesforce Topics are primarily used for Experience Cloud community organization while multi-select picklists are better for case classification and reporting.

Intercom Teams map to Salesforce Queues (for Case routing) or Groups (for reporting visibility). We preserve team membership by mapping each Intercom team member's admin ID to the corresponding Salesforce User. If Omni-Channel is configured, the Queue maps to an Omni-Channel Service Channel with routing configurations rebuilt separately.

Intercom Admins map to Salesforce Users by email match. We resolve active admins first, then flag any admin without a matching Salesforce User in a reconciliation queue for the customer's admin to provision. Inactive Intercom admins may map to inactive Salesforce Users if historical assignment is required.

Intercom Segments are dynamic audience definitions recomputed at query time and do not have a direct Salesforce equivalent. We capture the segment membership snapshot at migration time as a static report or list view in Salesforce, and we document the segment criteria so the customer's admin can rebuild the dynamic logic as a Salesforce Report or List View filter.

Intercom Tickets (distinct from Conversations in the data model) map to Salesforce Case. Ticket fields, statuses, priority, and custom ticket attributes map to corresponding Case standard and custom fields. If the customer uses both Tickets and Conversations in Intercom, we clarify during scoping whether these represent separate support workflows that should map to different Case Record Types in Salesforce.

Intercom Custom Attributes on Contacts and Companies map to Salesforce Custom Fields on Contact and Account. We audit the full attribute list via the Intercom Data Attributes API during scoping, map each attribute to a typed Salesforce field (Text, Number, Date, Picklist, Checkbox), and pre-create the destination fields before migration begins. Custom attributes on Conversation map to Case custom fields with the same approach.

Intercom Custom Objects migrate to Salesforce Custom Objects with equivalent API names (with __c suffix). We pre-create the destination schema including all custom fields and lookup relationships before any data import. Custom Object Instances reference Contacts or Companies, so we resolve parent record IDs during the contact and company migration phases before inserting Custom Object records.