Merge duplicate cases, contacts, and companies in Supportbench

Merging brings duplicate records together so the team can work from one history. It is useful when two cases describe the same request, two Contact records represent the same person, or two Company records represent the same organization. The record you choose to keep is called the target or survivor; the other record is the source. Choose that direction carefully. A merge moves supported history and relationships, but it does not automatically choose the best value from every field or preserve every side effect for later undo.

Decide whether a merge is the right operation  ·  Prepare a merge another agent can understand  ·  Merge one case into another  ·  Understand what a case merge changes  ·  Merge several source cases from the Case list  ·  Unmerge a case when the available rollback is appropriate  ·  Merge duplicate Companies  ·  Merge duplicate Contacts  ·  Verify the operational outcome  ·  Troubleshoot a merge

Decide whether a merge is the right operation

Before beginning, agree which record is authoritative. Compare names, identifiers, company/contact associations, open work, integration context and any customer login. If the relationship is uncertain, investigate first. Do not merge merely to make a report look cleaner.

Prepare a merge another agent can understand

1. Open both records and verify their IDs. Similar names are not enough, especially where a customer has several subsidiaries or shared email addresses.
2. Choose the survivor deliberately. For a case, consider the active customer conversation, assigned owner, current service commitments and the record colleagues already use. For a Contact, consider the intended portal identity. For a Company, review its parent and child relationships.
3. Record why the records are duplicates and any fields or relationships that need a deliberate correction afterward. A short internal case note or your approved data-maintenance record can make the decision traceable.
4. Coordinate with anyone actively editing or replying from either record. Completing a merge is not a substitute for agreeing who sends the next customer update.
5. Check your access. Case View merge requires case editing and the applicable bulk-link/merge capability, plus access to both cases. Company and Contact merge require their respective edit access. An administrator should review missing capabilities rather than broadening unrelated permissions.

Merge one case into another

1. Open the source case—the duplicate you no longer want the team to work separately. Check its ID, subject, Company and Contact.
2. Open Actions. In Merge / Split, select Merge this Case.
3. Search for the target case by Case ID or subject in the authorized picker, then select the returned case you intend to keep. The separate Case List bulk workflow below provides manual Case ID entry.
4. Choose Review merge. Read the source-to-target direction shown in the review. Recheck the target’s customer context before continuing.
5. When offered, decide whether to Add the source Case primary Contact as a secondary Contact on the target. This prompt is conditional. Choose based on who should participate in that case; do not assume the merge changes its primary Contact.
6. Select Merge Case and read the result. If the response is uncertain, inspect both records and the merge history before submitting again.
7. Open the target and verify the moved activity history and files. Review its owner, state, primary and secondary Contacts, service commitments and next customer update. Confirm that the source is shown as merged.

Understand what a case merge changes

Customer context is a consequential part of the decision. Moving history into another case can place it under a different working record. Confirm that the destination is appropriate for that information and inspect the resulting customer access and participants.

Merge several source cases from the Case list

1. In the Case list, select only the source cases that should become part of one target. Leave the target out of the selection.
2. Choose Merge in the selected-row action toolbar. The dialog is Merge Cases into….
3. Search for the survivor by Case ID or subject. Alternatively, enter Case ID to merge into and choose Use Case.
4. Review the selected sources and the target, then select Merge Cases.
5. Inspect every returned result. Sources are processed individually; a bulk merge can partly succeed. Reconcile which cases merged and which failed before taking further action.
6. Open the target to verify the combined history and current fields. Retry only a source confirmed not to have completed, after correcting its actual problem.

Do not treat a bulk merge as one all-or-nothing transaction or one shared undo. For a small number of important customer cases, individual review can be easier to verify.

Unmerge a case when the available rollback is appropriate

Case View can expose an Unmerge action in Merged Cases history. This is a case-specific rollback, not a universal undo for every record type or every change made since the merge.

1. Open the relevant case’s Actions tab and inspect Merged Cases. Identify the correct source and destination.
2. Review any work performed after the merge and coordinate with the current owner. Check whether restoring the source will require follow-up changes to ownership, customer communication or reporting.
3. If the authorized history entry offers Unmerge, select it and review the Unmerge Case confirmation.
4. Complete the action and inspect both records. The rollback restores the recorded source history and supported attachment/discussion/audit relationships, removes the merge entry/marker and reopens the source.
5. Reconcile the current fields and logged time. Rollback does not subtract the source’s accumulated time from the target, and it does not reverse every later target change or side effect.

If Unmerge is unavailable, have the administrator review the history and permissions. Do not promise a perfect restoration, and do not create another merge in the opposite direction as a substitute for the supported rollback.

Merge duplicate Companies

1. Open the source Company and choose Merge Company. For multiple sources, select their rows in the Company list and use Merge.
2. In Merge Companies, use Company to keep to search by Company name or ID and choose the survivor.
3. Review the source and survivor identities, primary customer relationships, parent/child structure and any integration ownership. Practice and customer records cannot be combined across those contexts.
4. Select Merge Companies. Inspect the result for each source; multiple Companies can partly succeed.
5. Open the survivor and check Cases, Contacts and Assets. Its profile fields remain; the source Company is soft-deleted. Supported source Cases, Assets, active Contacts’ primary Company and email-Company associations move to the survivor. Contact identities are not themselves merged.
6. Review the hierarchy separately. The merge does not copy the source’s Parent to the survivor. If the source had child Companies, deleting that source clears those children’s Parent links. Reestablish the intended supported relationships deliberately.

Merge duplicate Contacts

1. Open the source Contact and choose Merge Contact. Confirm this is the duplicate identity you intend to remove.
2. In Merge Contacts, use Contact to keep to search by ID, name or email. Select the survivor.
3. Read the confirmation. It identifies the source and target and explains that the source will be deleted. If both Contacts have portal logins, only the survivor’s login is kept.
4. Review Company affiliations, email aliases, custom-field values, portal profiles/subscriptions and current case participation. Resolve an ambiguity before committing the merge.
5. Choose Merge Contacts and read the returned result. Conflicting email ownership, overlapping portal profiles, incompatible single-value custom fields or portal subscription/publication records can block the operation. Correct the specific conflict with the responsible administrator.
6. Open the survivor and check its primary/secondary case relationships, emails, Assets and supported Company affiliations. Verify the intended portal login using the approved customer-access test process.

The target retains its credential when both Contacts have one; a sole source credential may transfer. Supported email aliases and related records transfer subject to uniqueness and compatibility checks. Multi-value custom fields can remain additive. Local integration mappings are reset as part of the merge; do not assume a remote CRM contact is deleted or automatically reconciled. There is no Contact merge undo action in the current Core interface.

Verify the operational outcome

• The intended target still has the expected identity and current owner/context.
• Important case history and attachments can be opened from the survivor.
• The customer’s primary and secondary participants, Company affiliations and portal access still match the intended relationship.
• Company hierarchy and active Contact/Asset assignments have been checked when those records were merged.
• Per-source results are reconciled for bulk operations; failed records have a clear next action.
• The team knows which case or customer record to use, and the next customer update has one responsible owner.

Troubleshoot a merge

Continue learning

• Work a case from first response to resolution
• Manage Companies and Contacts
• Use Assets and Asset Categories in customer support