Source: HighLevel merge guide.
Key takeaways
- Confirm that the records belong to the same person before combining them.
- Save the history references and field decisions needed to check the result.
- Verify the surviving CRM identity and messaging connection separately.
Do these contacts actually represent the same person?
Start with identity, not the duplicate label. Compare the names, email addresses, phone ownership and context of the conversations. Ask the client account owner to resolve contradictions that the records cannot explain.
For example, imagine a hypothetical household where different people use a shared phone number. A matching number would not justify combining their appointment requests or private conversation context. Keep the contacts separate until the business can explain who each record represents.
A changed phone number needs a different review. Confirm whether the older number still belongs to the person, whether it should remain historical information, and which number is approved for future contact. Do not pick the number simply because its thread has more recent activity.
Agencies reviewing the broader connection can use the GoHighLevel iMessage integration guide. For this task, the decision is narrower: which customer identity should the agency retain, and what evidence supports it?
What should you record before opening the merge window?
Create a pre-merge worksheet in the client’s approved workspace. Use a separate entry for each source contact, with an intended-result column alongside it. Record actual IDs rather than relying on display names.
| Record area | Capture before merging | Intended result |
|---|---|---|
| CRM identity | Location, contact ID and record link | Named surviving contact ID |
| Phone fields | Primary and additional numbers, including country code | Confirmed destination for future texts |
| Conversation history | Thread references, message references and timestamps where available | History the team expects to find |
| Field conflicts | Current values and the reason for each selection | Written field decisions |
| Active automation | Workflow name, current step, wait state and pending action | Reviewed continuation plan |
| Messaging connection | Beam workspace, assigned line and known CRM mapping | Verified connection to the survivor |
Capture representative inbound and outbound messages from each source record. Choose messages with recognizable context, such as an appointment change or a question awaiting an answer. Note direction, timestamp, sender and recipient so a reviewer can distinguish similar-looking threads.
Keep necessary evidence accessible to the reviewer without copying entire customer conversations into a general team document. Where attachments matter, record how to find them and what the reviewer should verify. A screenshot can document visible content, but it should not be described as a complete or restorable archive.
Mark unavailable identifiers as unavailable. Ask the integration owner how to inspect them instead of guessing a value from the contact’s name or number.
Which values does GoHighLevel keep when contacts merge?
HighLevel says the selected master survives and generally keeps its existing values. Reviewable conflicts can use the selected value. Custom fields from another record fill blanks on the master; they do not overwrite populated master custom fields. Appointments, payments, orders and invoices default to the master’s values. The guide describes combining relevant conversations and other contact data. HighLevel field precedence documentation.
Turn those rules into explicit decisions. Beside each conflicting phone or custom field, write the intended value and its evidence. If a populated field is outdated, resolve that discrepancy deliberately rather than expecting merge behavior to correct it.
Treat the proposed master as a business decision. Review its appointments and transaction context with the account owner before proceeding. The contact with the longest conversation is not automatically the record the business should retain.
When ready, HighLevel’s manual path is Contacts, Smart Lists, select contacts, More, Merge. Choose the master and review All Fields before confirming. HighLevel manual merge instructions.
How should you review active workflows before merging?
Inventory the automation on every source record before changing anything. Note the current step, intended next action and any conditions tied to phone fields or custom fields. Include scheduled follow-ups that staff expect to happen later.
HighLevel documents workflow execution transfer to the master. When that master already runs the same workflow, its existing execution is retained and the extra run can end. Waits, goals, re-entry settings and contact-specific actions can affect the result. HighLevel workflow merge behavior.
For each pending action, write whether it should continue, be held for review or be retired. If texting could occur while fields are being reconciled, arrange a controlled maintenance window and use the available workflow controls to hold affected activity. Record the change and who will restore it.
Do not automatically re-enroll the surviving contact to compensate for uncertainty. Compare its actual workflow state with the written continuation plan first. This review is about preserving the intended customer journey through an identity change.
Why does Beam mapping need a separate check?
A CRM conversation identifier and an external messaging connection answer different questions. HighLevel’s provider documentation says it maintains one conversation ID per contact. That describes its conversation model; it does not prove how an external Beam mapping behaves after a merge. HighLevel Conversation Providers documentation.
Compare the surviving contact ID and location with whatever mapping your integration actually uses. Also check the approved recipient phone field, Beam workspace and assigned sending line. If the connection exposes no mapping details, ask the implementation owner to verify them through supported tools.
Do not invent a repair endpoint or assume an old contact ID redirects to the survivor. For custom implementations, the iMessage API overview helps frame the integration review, but it is not evidence of automatic merge reconciliation.
Keep this distinction in the worksheet: history located, identity confirmed, mapping verified. A tidy CRM timeline can satisfy the first check while leaving the others unresolved.
How can you verify the surviving record in a controlled way?
Use the saved inventory as an acceptance checklist. The following is a proposed agency review procedure, not a claim that every integration exposes the same controls.
- Confirm the survivor. Open the retained contact directly. Compare its ID, location and phone fields with the intended-result column.
- Locate the history. Find the saved message examples from each source. Check context, direction and timestamps, plus any required attachment access.
- Inspect automation. Compare active execution and the next intended action with the continuation plan. Resolve unexplained differences before resuming affected texts.
- Validate the connection. Have the integration owner check the surviving identity through the supported validation path. Do not treat a successful CRM save as messaging validation.
- Observe message routing. Rehearse on agency-controlled test contacts first. For a merged customer record, coordinate any live verification with the account owner and a willing recipient. Confirm the intended line and destination, then verify that a reply reaches the surviving contact’s expected conversation.
Record what actually passed. An outbound message arriving does not by itself demonstrate that replies attach to the correct CRM identity. Likewise, a test contact proves the tested setup, not every customer’s mapping.
If anything differs from the worksheet, hold the affected automation and document the exact mismatch. Keep the original references available for support review. Avoid further merges as an improvised repair while the identity remains uncertain.
Who should approve the completed identity review?
Assign a named agency owner to close the worksheet. Record the source IDs, surviving ID, field decisions, history checks, mapping evidence and unresolved items. The client team should know which contact to use when the next reply arrives.
For broader onboarding responsibilities, the agency GoHighLevel texting guide helps place this review inside the client rollout. If the client needs ongoing ownership of its sales automation, MetaTech managed services is a contextual option to discuss implementation and maintenance responsibilities.
Resume affected activity only when its reviewer can explain the result. For help evaluating the Beam connection, Text our team to try it.
What are the frequently asked questions about contact merges?
Should contacts with a shared phone number be merged?
Only after confirming they represent the same person. A shared family or office number is a reason to investigate, not enough evidence to combine identities.
Does a completed CRM merge prove the Beam mapping is correct?
No. Verify the surviving contact ID, connected location, phone field and message path. The cited HighLevel documentation does not establish how an external Beam mapping changes after a merge.
What if some text history cannot be verified before the merge?
Leave the records separate while you investigate. Record the missing conversation or message reference and have the integration owner explain where that history is stored.
Is a pre-merge worksheet a restorable backup?
No. It records the identities, field decisions and evidence needed for review. Screenshots and saved references do not establish that the original application state can be restored.