---
title: "Salesforce Acquires Fin: The AI Helpdesk Migration Guide"
slug: salesforce-acquires-fin-the-ai-helpdesk-migration-guide
date: 2026-06-16
author: Raaj
categories: [Salesforce, Intercom]
excerpt: Salesforce acquired Fin for $3.6B. The technical guide to migrating conversational helpdesk data into Salesforce without breaking AI training context.
tldr: "Migrating Fin to Salesforce requires message-level schema mapping, audit field preservation for original timestamps, and point-in-time delta execution — not sync bridges."
canonical: https://clonepartner.com/blog/salesforce-acquires-fin-the-ai-helpdesk-migration-guide/
---

# 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](https://www.salesforce.com/news/press-releases/2026/06/15/salesforce-signs-definitive-agreement-to-acquire-fin/?bc=HL))

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](https://www.intercom.com/blog/announcing-fin-apex-the-age-of-vertical-models-is-here/))

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](https://www.salesforce.com/news/press-releases/2026/06/15/salesforce-signs-definitive-agreement-to-acquire-fin/?bc=HL))

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](https://www.salesforce.com/platform/agentforce-platform))

| | **Fin (ex-Intercom)** | **Salesforce Agentforce** |
|---|---|---|
| **Deployment** | Pre-trained, deployable in days | Enterprise customization required |
| **AI Model** | Proprietary Apex, post-trained on support transcripts | LLM-agnostic, grounded via Data Cloud RAG |
| **Data Requirement** | Knowledge base + conversation history | Full Data Cloud ingestion pipeline + custom retrievers |
| **Pricing** | $0.99 per resolution | Consumption-based per conversation |

> [!WARNING]
> **The Billing Trap:** Fin charges $0.99 per resolution. An "assumed resolution" is billed when the customer leaves after Fin's answer without asking for more help — even if the customer simply abandoned the conversation. This can cause unpredictable cost spikes for high-traffic operations. ([intercom.com](https://www.intercom.com/pricing?tab=1&utm_source=openai))

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](https://www.salesforce.com/agentforce/how-it-works/?bc=OTH))

**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](https://www.salesforce.com/agentforce/resources/agentforce-and-rag/))

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](https://www.salesforce.com/blog/context-rot/?utm_source=openai))

> [!TIP]
> If screenshots, PDFs, or uploaded files contain the answer, move the file **and** extract text from it. Salesforce's Data Library documentation says Data Cloud chunks text, not images — image-only attachments will not ground the agent unless you add OCR or another text representation. ([help.salesforce.com](https://help.salesforce.com/s/articleView?id=004333412&language=en_US&type=1&utm_source=openai))

For a deeper look at data preparation for AI consumption, see [CRM & Helpdesk Data Prep for AI Agents: 2026 Playbook](https://clonepartner.com/blog/blog/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.

```json
// 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"
  }
}
```

> [!WARNING]
> **Export Limitation:** Intercom's CSV and S3 exports do not include full conversation transcripts. CSV exports contain reporting metadata, not message content. Reporting datasets exclude outbound conversations where the customer never replied, and transcript-style exports exclude internal notes. To get full message content, you must use the REST API and retrieve each conversation individually. There is no bulk transcript export. ([intercom.com](https://www.intercom.com/help/en/articles/2046229-export-your-conversations-data))

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](https://help.salesforce.com/s/articleView?id=sales.emailadmin_enhanced_email_considerations.htm&language=en_US&type=5&utm_source=openai))

The schema mapping:

| **Intercom Object** | **Salesforce Target** | **Complexity** |
|---|---|---|
| Conversation (metadata) | Case | Moderate — field mapping + status translation |
| Conversation Parts (messages) | EmailMessage / CaseComment | High — threading, author attribution, timestamp preservation |
| Conversation Parts (bot actions) | Case Activity History / Custom Object | High — no native Salesforce equivalent |
| Fin AI summaries | Case custom field or Knowledge Article | Moderate |
| Tags / Attributes | Case fields or record types | Low-moderate |
| Attachments | ContentVersion → ContentDocumentLink | Moderate — binary transfer + parent linking |

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](https://developers.intercom.com/docs/references/2.14/rest-api/api.intercom.io/conversations/searchconversations?utm_source=openai))

### 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](https://developer.salesforce.com/docs/service/interaction-service-api/references/interaction-service-reference/api-conversationHistory.html?utm_source=openai))

**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](https://clonepartner.com/blog/blog/why-migrate-to-salesforce/).

## 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](https://zapier.com/apps/intercom/integrations/salesforce?utm_source=openai))

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:

```json
{
  "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](https://developers.intercom.com/docs/references/2.14/rest-api/api.intercom.io/conversations/searchconversations?utm_source=openai))

For more on keeping support running during the move, see [Zero-Downtime Helpdesk Migration: How to Keep Support Running During the Move](https://clonepartner.com/blog/blog/zero-downtime-helpdesk-migration/).

## 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
```

> [!CAUTION]
> This permission only works at **creation time**. You cannot retroactively update `CreatedDate` on existing records. If you load records without this enabled, you need to delete and reimport. There is no undo. ([help.salesforce.com](https://help.salesforce.com/s/articleView?id=000334139&language=en_US&type=1&utm_source=openai))

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](https://help.salesforce.com/s/articleView?id=000176484&language=en_US&type=1&utm_source=openai))

### 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.

```csharp
// 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](https://learn.microsoft.com/en-us/dynamics365/developer/reference/entities/product?utm_source=openai))

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](https://clonepartner.com/blog/blog/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.

> Planning a Fin-to-Salesforce migration or consolidating your helpdesk into Service Cloud? Our engineers will map your data model, audit field requirements, and timeline on a free 30-minute call.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### What is the Salesforce Fin acquisition?

On June 15, 2026, Salesforce signed a definitive agreement to acquire Fin (formerly Intercom) for approximately $3.6 billion. Salesforce plans to integrate Fin's AI agent technology — powered by its proprietary Apex model — into the Agentforce platform. The deal is expected to close in Q4 of Salesforce's fiscal year 2027.

### How does Fin's Apex model differ from Agentforce?

Fin's Apex is a pre-trained, domain-specific model that can be deployed in days and achieves roughly 76% autonomous resolution. Agentforce uses Retrieval-Augmented Generation (RAG) grounded in Salesforce Data Cloud, requiring enterprise customization including data ingestion pipelines, custom retrievers, and prompt templates. Agentforce is more flexible but demands significantly more setup.

### How do you preserve historical timestamps when migrating to Salesforce?

Enable the 'Set Audit Fields upon Record Creation' permission in Salesforce Setup and assign it to your integration user via a permission set. This lets you write original CreatedDate and CreatedById values during API-based record creation. Without this, Salesforce overwrites all creation dates with the migration timestamp, destroying the chronological context AI agents need.

### Can you export full conversation transcripts from Intercom?

Not through built-in exports. Intercom's CSV and S3 exports do not include conversation transcripts or full message content. You must use the REST API to retrieve each conversation individually, including its conversation parts. There is a 500-part limit per conversation and tight API rate windows.

### Should Intercom history land in Salesforce Cases or Messaging objects?

Cases fit teams operating in a case-centric Service Cloud model with queues, SLAs, and escalation rules. Messaging objects via the Interaction Service API preserve richer chat semantics but store content off-platform, outside SOQL and standard reporting. Decide before loading any records — your AI grounding and rep workflow depend on it.