Problem
Duplicate customer profiles split conversations, tickets, properties and derived audiences. A merge can repair that fragmentation, but it can also select the wrong survivor, compress lineage and change downstream customer actions.
Why it matters
Intercom now provides a move preview, a dedicated teammate permission and a REST API in Preview. Those controls make a disciplined release gate possible, but the business still has to define identity evidence, field authority, downstream holds and verification.
Trigger and scope
Use the gate when two person or customer profiles may represent the same entity and the merge can affect service history, lifecycle eligibility, account reporting or customer communication. Keep trivial display-only cleanup outside the gate only when it cannot alter identity, association, permission or downstream action.
Define the platform operation precisely. A merge is not the same as linking two records, redirecting an identifier, deduplicating an export or recomputing an audience. Record the source profile, intended survivor, affected object type and business consequences before approval.
Owner and evidence packet
Assign a business owner for the survivorship policy, a platform administrator for permissions and execution, a data owner for cross-system identity and an exception owner for ambiguous cases. The executor should not be forced to invent field authority during the merge.
The review packet should show stable external IDs, verified contact points, account relationships, current owners, activity ranges, consent or preference evidence, conflicting fields, the proposed survivor and every downstream system that uses either ID. Link the source records rather than copying only a summary.
Approval and execution
Use the platform preview where available, then compare it with the business packet. Intercom's changelog says the sidebar flow previews what will move, but the organization must still decide whether those items belong together and which value remains authoritative.
For API batches, require a dry run, stable repair ID, idempotency, maximum batch size and a stop rule for conflicts or post-approval changes. Treat Preview endpoints as target-account test surfaces. Do not let a successful response automatically release customer-facing work.
Verification and release
Read the surviving record after execution and inspect the expected conversations, tickets, notes, identifiers and account association. Query or inspect the old identifier according to the platform's documented behavior. Preserve the request and result alongside the approval evidence.
Re-evaluate derived state, including segments and audiences, and test representative exports. Release held customer workflows only after the destination systems that matter for that consequence show the intended identity and current business state.
Step-by-step workflow
- Open a merge case with the source profile ID, proposed survivor ID, detector rule, match reasons and accountable reviewer.
- Collect stable external identifiers, verified contact points, account associations, current owners, activity ranges and preference evidence for both profiles.
- Flag conflicts in durable IDs, employer or account, legal or billing identity, consent, active ownership and high-impact commercial fields.
- Choose the survivor using the approved identity policy; send unresolved cases to an exception queue instead of forcing a match.
- Map field authority and mark derived values that must be recomputed rather than copied.
- List downstream systems, exports, audiences and customer-facing automations that reference either identifier.
- Apply a temporary hold to high-impact actions such as renewal outreach, lifecycle messages, owner changes or entitlement decisions.
- Review the platform preview and compare its movement list with the business evidence packet.
- Execute manually for isolated cases or through an idempotent, dry-run-tested API job for an approved batch.
- Read the surviving record, old identifier and required associations after the platform reports completion.
- Recompute audiences or scores, run representative survey or analytics exports and inspect destination sync results.
- Release held workflows only when current identity, preference, account and commercial context match the approved state.
- Record exceptions, correction work and upstream duplicate cause; update the detector or source process when failures repeat.
CRM fields and signals needed
- Source and destination profile IDs
- CRM contact and account IDs
- Product user and workspace IDs
- Verified email or phone evidence
- Conversation, ticket and note ranges
- Consent and preference source
- Current account and commercial owner
- Audience and segment memberships with evaluated-at time
- Merge actor, permission and repair ID
- Previewed movement list
- Execution response and post-read result
- Destination reconciliation state
- Hold and release timestamps
- Correction or rollback owner
Operating quality check
Use this check before adding more tooling. The goal is to prove that the workflow is owned, current, and inspectable inside the system of action.
| Area | Healthy pattern | Risk pattern |
|---|---|---|
| Identity | Durable identifiers agree or the approved policy resolves the case. | Identifiers conflict or the match depends only on mutable labels. |
| Authority | Field sources and merge permission are explicit. | The executor must choose authoritative values ad hoc. |
| Downstream | Consequential destinations and holds are mapped. | Audience, export or customer actions can change without review. |
| Recovery | Evidence, correction owner and stop path are retained. | The operation cannot be reconstructed or contained. |
Common mistakes
- Selecting the survivor from the newest email address alone.
- Copying derived audience or score fields instead of recomputing them.
- Treating the platform success response as end-to-end verification.
- Allowing a large API batch without idempotency and stop conditions.
- Releasing lifecycle or renewal actions before checking current preference and account context.
- Deleting the evidence needed to reconstruct the decision.
- Measuring only duplicates removed and ignoring expensive corrections.
Customer identity repair review
- Survivor and source IDs recorded
- Conflicts resolved or exception opened
- Preview reviewed
- Execution verified by post-read
- Derived state recomputed
- Required destinations reconciled
- Customer-action hold released or escalated
- Evidence packet closed by named owner
Example operating rhythm
- Daily during an active repair batch: review conflicts, stopped jobs, destination mismatches and held customer actions.
- Weekly: sample approved merges from every detector rule, inspect downstream evidence and age unresolved cases.
- Monthly: review false matches, corrections, recurring duplicate causes, permission membership and unused hold logic.
- Quarterly or after a material vendor change: retest preview, API, field movement, derived-state recomputation and one recovery scenario.
Tooling options
- Intercom preview and teammate permission for bounded manual merges.
- Intercom REST API Preview only after target-account testing and an idempotent approval workflow.
- CRM and warehouse queries for stable identity and account associations.
- Hightouch or another governed activation layer for audience recomputation and destination reconciliation.
- Amplitude or another analytics surface for representative post-merge export checks.
- A ticket or case system for evidence, exception ownership, hold and release state.
Source notes
These sources support the workflow model and product concepts. They do not prove a specific business outcome, benchmark result, or vendor claim.
- Intercom: Merge duplicate users into one profile: Official product changelog shared September 28, 2026; describes preview, teammate permission and REST API Preview.
- Amplitude: User properties on survey responses: Official changelog dated September 23, 2026; describes user-property columns, DAC filtering and CSV exports.
- Hightouch: September 2026 changelog: Official month-level September 2026 changelog; no item-level publication day is stated.
- HubSpot: Fall 2026 Spotlight developer updates: Official changelog announced September 15, 2026; describes connected-app ownership, activity, events and deactivation warnings.
Last updated: 2026-09-29
Decision frameworks to read next
FAQ
Should every duplicate be merged automatically?
No. Automate only cohorts where stable identifiers, account relationships and field authority are reliable. Route conflicts and ambiguous employer or consent cases to review.
Is Intercom's preview enough for approval?
It is useful platform evidence, but the business packet must also show cross-system identity, authoritative fields and downstream consequences.
What must be verified after a merge?
Read the survivor, inspect important moved history, test required associations, recompute derived state and reconcile any destination that can trigger consequential work.
How should API batches be controlled?
Use a dry run, unique repair ID, idempotency, stable source and destination IDs, small batches, conflict stops, evidence retention and independent post-reads.