Salesforce Acquires Fin: The AI Helpdesk Migration Guide

On June 15, 2026, Salesforce announced a definitive agreement to acquire Fin — the company formerly known as Intercom — for approximately $3.6 billion. (salesforce.com)

If you run support operations on Intercom, the question is not whether this headline is big. It is how to move years of conversational history into Salesforce without breaking the timestamps, authorship, attachments, and resolution signals that AI agents need for grounding. The safest Fin-to-Salesforce migration strategy is a staged historical load plus a final delta cutover — not a long-lived sync bridge.

Here is the technical blueprint.

The News Breakdown: Salesforce Acquires Fin for $3.6B

Fin's core product is an AI agent that resolves customer queries end-to-end across live chat, email, WhatsApp, SMS, phone, and Slack. It is powered by Apex, a proprietary model that Fin post-trained specifically for customer support. In March 2026, Intercom said roughly 100% of English-language chat and email conversations were already running on Apex. (intercom.com)

Salesforce said Fin resolves approximately 76% of support volume end-to-end without human intervention and brings more than 30,000 business clients. The deal is expected to close in Q4 of Salesforce's fiscal year 2027, subject to regulatory clearances. (salesforce.com)

Salesforce plans to fold Fin's technology into Agentforce, its enterprise AI agent platform. Agentforce takes a fundamentally different architectural approach — it uses Retrieval-Augmented Generation (RAG) through Salesforce Data Cloud rather than a single pre-trained model. You ingest structured and unstructured data into Data Cloud, build custom retrievers in Einstein Studio, and connect those retrievers to agents via prompt templates. Without this pipeline, Agentforce works from knowledge articles and standard CRM objects alone — fine for generic questions, insufficient for personalized, context-aware resolution. (salesforce.com)

The acquisition logic is straightforward: Fin gives Salesforce a faster, packaged service-agent entry point, while Agentforce remains the enterprise control plane for governance, unified data, and cross-system action. That is good news for buyers who want both speed and enterprise controls. It is bad news for teams that think the data migration is a side quest.

The Agentic Enterprise: Structuring Data for AI

Two terms now define how Salesforce frames its product strategy.

Agentic Support is a support model where AI agents autonomously handle customer interactions from first contact through resolution — triaging, retrieving context, executing actions, and escalating only when confidence is low. This is not a chatbot answering FAQs. It is software that reasons over your data and takes action. (salesforce.com)

Autonomous Resolution is the metric that measures it: the percentage of customer issues fully resolved by the AI agent with zero human intervention. Fin's billing model makes this explicit — a "resolution" is the billable unit.

Here is the part most teams miss: AI agents are only as good as the data they are grounded in. Salesforce's Agentforce guidance centers on RAG over structured and unstructured enterprise data — emails, support tickets, files, call notes, and free-text fields. Data Cloud is the layer that unifies and retrieves that data. (salesforce.com)

If your migration flattens message threads, overwrites CreatedDate, drops attachments, or loses the link between a contact and the company they belonged to at the time, the agent is grounded on damaged context.

The minimum data model for AI-ready support history:

• Canonical customer and account identity linked at time of interaction
• One record per message, note, bot action, or system event — not one giant text blob per ticket
• Original sender role: customer, agent, bot, or system
• Original timestamps with time zone assumptions preserved
• Thread and channel identifiers
• Attachment records plus extracted text or OCR where files carry meaning
• Explicit fields for resolution outcome, handoff reason, sentiment/CSAT, and AI summary
• Stable foreign keys from every event back to the parent case or session

Do not dump a 200-message thread into one Case Description and call it AI-ready. Salesforce recently warned about context rot in long multi-turn agents: long, multi-topic content burns context budget and crowds out the specific history the agent actually needs. For migration design, chunkable message-level history beats a monolithic blob every time. (salesforce.com)

For a deeper look at data preparation for AI consumption, see CRM & Helpdesk Data Prep for AI Agents: 2026 Playbook.

The Consolidation Challenge: Mapping Intercom Logs to Salesforce

The hardest part of moving from Fin to Salesforce is not contacts or companies. It is the conversational data.

Intercom structures conversations as a parent object containing an ordered list of conversation parts — individual messages, actions (assignment, snooze, close), bot interactions, and internal notes. Each part carries its own author, timestamp, body (HTML), and part type. The API returns a maximum of 500 parts per conversation.

// Example: Intercom Conversation Part
{
  "type": "conversation_part",
  "id": "part_12345",
  "part_type": "comment",
  "body": "<p>I need help with my invoice.</p>",
  "created_at": 1718452800,
  "author": {
    "type": "user",
    "id": "usr_9876"
  }
}

Salesforce Service Cloud structures support interactions as Cases with child EmailMessages, CaseComments, or LiveChatTranscript records. There is no native equivalent of Intercom's multi-part conversational thread model. Salesforce says EmailMessage is intended to remain an accurate representation of the mail record and is not editable through the UI or API — import mistakes here are expensive to fix. (help.salesforce.com)

The schema mapping:

Three pain points surface in every Intercom-to-Salesforce migration:

1. Thread ordering. Intercom parts are inherently ordered. Salesforce EmailMessages and CaseComments are not — you need MessageDate or custom sort fields to reconstruct the original conversation flow.

2. Author attribution. Intercom distinguishes between contacts, admins, bots, and the system itself. Salesforce maps these differently — bot-originated messages have no natural home unless you create a dedicated integration user or custom field.

3. AI interaction metadata. Fin logs which model answered, whether the response was grounded, and whether the customer confirmed resolution. None of this maps to standard Service Cloud fields. If you want Agentforce to learn from Fin's resolution patterns, this metadata needs a custom object or extended Case fields.

One more sharp edge at the API level: Intercom's Conversations Search API does not support filtering by company_id. You resolve company-to-contact first and search using contact_ids. Dataset exports also reflect user data as it existed at the start of the conversation, not the state at cutover time — this creates false mismatches if your account model changed mid-thread. (developers.intercom.com)

When Salesforce Messaging Is the Better Target

If the target experience is Salesforce Messaging rather than a pure case archive, Salesforce provides the Interaction Service API to ingest third-party conversation history. It can send historical entries with client timestamps, sender roles, message payloads, and attachments into new or existing MessagingSession records. This preserves richer chat semantics than forcing everything into email-shaped records.

The trade-off: Salesforce says the actual message content for enhanced conversations is off-platform, not queryable by SOQL or standard reporting, and the Conversation Data GET API is limited to 90 requests per user per minute. You also need Bring Your Own Channel enabled. (developer.salesforce.com)

Decide whether Salesforce will treat history as Cases or MessagingSession records before you load a single record. Your AI grounding, reporting, and rep workflow all depend on this choice.

Teams exploring the broader case for helpdesk consolidation should read Why Top-Performing Teams are Migrating to Salesforce Service Cloud.

The Migration Blueprint: Point-in-Time Delta over Sync Bridges

When facing a platform consolidation, the instinct is to build a continuous sync bridge — middleware that keeps Intercom and Salesforce running in parallel until cutover.

This is risky for helpdesk consolidations:

• Duplicate records. Bidirectional sync between a conversational platform and a case-based CRM creates constant conflict resolution problems. A single Intercom conversation can generate dozens of sync events as parts are added.
• API rate limits. Intercom's API has tight rate windows. Salesforce's Bulk API has batch size limits. A continuous sync that hits either ceiling starts dropping records silently.
• Schema drift. As teams customize either platform during the transition, field mappings break. What was a clean mapping in month one becomes a data quality problem by month three.

Sync tools are fine for operational coexistence — creating Salesforce contacts from new Intercom users, for example. They are a poor primary strategy for reconstructing years of support history. (zapier.com)

The better approach: a point-in-time delta migration.

1. Run a full historical migration of all conversation data into Salesforce during a maintenance window.
2. Continue operating on Fin during the transition.
3. Execute a final delta migration that captures only records created or modified since the historical cut.
4. Cut over to Salesforce Service Cloud.

No middleware. No conflict resolution logic. No ongoing API consumption.

For the delta window, use Intercom's POST /conversations/search with a bounded updated_at query:

{
  "query": {
    "field": "updated_at",
    "operator": ">",
    "value": "<cutover_unix_timestamp>"
  }
}

Intercom paginates at up to 150 records per page. Pair this with a checkpoint table on your side. (developers.intercom.com)

For more on keeping support running during the move, see Zero-Downtime Helpdesk Migration: How to Keep Support Running During the Move.

Preserving Historical Timestamps for AI

This is where most DIY migrations quietly fail — and where the consequences for AI training are severe.

When you insert records into Salesforce via the API, the system stamps CreatedDate with the current timestamp. Your 2019 support tickets look like they were created today. For reporting, that is annoying. For AI grounding, it is catastrophic — Agentforce's RAG pipeline loses all chronological context. A support case from 2023 about a billing policy carries different weight than one from last week. Flatten that timeline and you degrade the agent's ability to reason about temporal patterns — seasonal spikes, product launch issues, evolving customer sentiment.

The fix: Enable "Set Audit Fields upon Record Creation."

This Salesforce permission allows you to write to normally read-only system fields — CreatedDate, CreatedById, LastModifiedDate, LastModifiedById — during record creation via the API.

// Enable via Setup → User Interface
// Check: "Enable Set Audit Fields upon Record Creation
//         and Update Records with Inactive Owners"

// Then assign the permission set to your integration user:
// System Permissions → Set Audit Fields upon Record Creation ✓
// Requires: Modify All Data permission

There is an ugly edge case with Enhanced Email. When you insert EmailMessage records, Salesforce auto-creates associated Task records. Those Tasks do not inherit the EmailMessage.CreatedDate — the Task gets the date of insertion. If your downstream reporting or automation uses Tasks as the canonical timeline, you can silently reorder history even when EmailMessage itself is correct. (help.salesforce.com)

overriddencreatedon for Dynamics and Dataverse Sources

If any source system is Dynamics 365 or Dataverse — common in M&A consolidation scenarios — use the overriddencreatedon field to preserve original creation dates. When you set this field during record creation via the SDK, Dynamics writes your value into CreatedOn and stamps OverriddenCreatedOn with the actual operation timestamp.

// Dynamics 365 SDK example
Entity contact = new Entity("contact");
contact["firstname"] = "Migrated Contact";
contact["overriddencreatedon"] = new DateTime(2021, 06, 15);
_service.Create(contact);
// CreatedOn → 2021-06-15
// OverriddenCreatedOn → actual migration timestamp

If you route data through Dynamics 365 as part of a multi-system consolidation and fail to map overriddencreatedon, your records arrive in Salesforce with the wrong origin dates twice over. (learn.microsoft.com)

Teams attempting this work in-house often underestimate the API-level precision required. For more on why that pattern fails, read How In-House Data Migrations Silently Kill Product Velocity.

Executing the Move with Strict Data Accuracy

A migration of this complexity — unstructured conversational logs, multi-part threading, AI metadata, audit field preservation — is a data engineering problem that touches API constraints on both source and target sides simultaneously.

At ClonePartner, this is the category of work we do every day. We have completed over 1,500 migrations across CRM and helpdesk platforms, including Intercom-to-Salesforce moves with full conversation history, timestamp preservation, and attachment integrity.

Our approach:

• Programmatic audit field handling as step one of every Salesforce-targeted migration — not an afterthought
• Point-in-time delta execution — full historical load, then a precision delta for the gap period
• Object-by-object validation against the source, including timeline QA
• Zero downtime — your support team never stops working

A solid QA checklist covers:

• Count parity by object and by day or week
• First and last message timestamps matching the source
• Attachment count and file-type parity
• Sender-role parity on sampled threads
• Correct parent-child linkage between contacts, companies, and cases
• Preserved AI summary, resolution, CSAT, and handoff fields

The Salesforce-Fin acquisition will accelerate consolidation across the support industry. The main decision is not Fin or Agentforce — it is which Salesforce data model your future agent and reps will actually use. Answer that first, and the migration plan becomes concrete.