Intercom adds governed profile merging for duplicate users

Intercom makes duplicate consolidation a visible workflow

Intercom's September 28 product note says teammates can now merge one duplicate user into another from the conversation sidebar. Before confirmation, the operator sees a preview of what will move. The company also added a teammate permission for the action and made developer-driven merging available through the REST API in Preview.

The update addresses a familiar support-operations problem. Two profiles can split conversations, tickets and notes, leaving an agent without the full customer history. Consolidation can improve continuity, but the product control does not decide whether two records truly represent the same person or which profile should survive. That policy remains a business responsibility.

Sources: Intercom product update

The survivor needs an explicit identity rule

A merge direction is consequential. The destination profile becomes the object through which future conversations and integrations operate. RevOps should define approved evidence such as stable external customer IDs, CRM contact IDs, verified contact points and current account relationships. Names, domains and email addresses can support a match, but they are mutable and should not win by themselves when stronger identifiers conflict.

The review packet should display both profiles, the detector's match reasons, relevant activity ranges, current owners and any contradictory account or preference evidence. An unresolved conflict should create an exception rather than a forced merge. A smaller queue of ambiguous cases is healthier than a clean-looking database built on hidden assumptions.

Preview and permission form the approval boundary

The preview is useful because the operator can inspect the history Intercom intends to move before making the change. The dedicated teammate permission gives administrators a way to limit the action to trained roles. Teams should test the actual field and history behavior in their target workspace, because the short changelog does not document a universal survivorship rule for every custom attribute or external integration.

Keep the approval actor, previewed movement, source and destination IDs, reason, execution time and post-merge record together. That evidence lets another operator reconstruct the decision when an account association, lifecycle audience or customer communication is later questioned.

API access turns repair policy into production code

The REST option is in Preview, which is an appropriate signal to test before scale. An automated job should start with a dry run, generate a stable repair ID, stop when an approved record changed and refuse to process the same pair twice. Small batches make containment and review easier than one large cleanup.

A successful API response is not the end of the workflow. Read the surviving profile, inspect the expected conversations or tickets and verify how the old identifier behaves. Then check the connected CRM, warehouse or lifecycle destination that matters for the use case. The destination read proves business state more reliably than the merge request alone.

Derived audiences should be recomputed

Segments, health scores, lifecycle eligibility and other derived values may change when two profiles become one. Do not copy those values as if they were permanent attributes. Recompute them from the surviving identity and current source evidence, and preserve the evaluated-at time.

For high-impact workflows, use a temporary hold between merge and release. Renewal outreach, support entitlement, commercial ownership or lifecycle messaging should wait until the current account, preference and contractual context is verified. Low-risk descriptive reporting can follow a lighter path.

What RevOps should measure

Count candidate pairs, reviewed pairs, conflicts that blocked automation, verified merges, downstream mismatches, corrections and the age of unresolved exceptions. Separate results by detector rule and source system. A rising merge count may reflect better detection or worsening upstream duplication; volume alone cannot distinguish them.

The operational goal is not simply fewer profiles. It is one explainable customer identity with traceable evidence and correct downstream behavior. Intercom now exposes a stronger mechanical boundary around merging. RevOps should use it to make survivorship, verification and recovery equally explicit.

Put the merge behind an operational handoff

The support administrator who confirms a duplicate is not always the person who owns the downstream consequence. Define a handoff from identity reviewer to CRM, lifecycle or data owner whenever the merged profile participates in a consequential workflow. The handoff should name the survivor, the held destinations, the checks still required and the person who can release them.

Include a recovery owner before execution. Intercom's short announcement does not promise a universal self-service undo flow, so the team should know how it will contain a wrong merge, correct connected records and contact vendor support if necessary. Recovery planning is part of approval, not an exercise to invent after a customer receives an incorrect message.

Finally, review the source of duplication. Repeated form creation, weak anonymous-to-known stitching, integration retries or inconsistent account-association rules can recreate the problem faster than a merge queue resolves it. Assign the upstream fix and use the merge program as diagnostic evidence, not as a permanent substitute for controlled record creation.