---
title: "Merging cases, and what merge destroys"
url: "https://trailassembly.com/case-merge-and-related-cases/"
topic: "Admin and Permissions"
published: "2026-09-15T06:33:23+00:00"
updated: "2026-10-06T13:55:39+00:00"
---

# Merging cases, and what merge destroys

**Briefly:** merging cases consolidates duplicates into one master and is not reversible. Parent and child cases are a different tool entirely, for one real problem that produced several reports, and nothing is merged or lost. People reach for merge when they want hierarchy, then find out afterwards what merge threw away.

## What merge does

You select a small number of cases, pick the master, and choose which field value wins for each conflicting field. Salesforce consolidates them.

## What merge destroys

Assume the following are at risk and verify in a sandbox before you let agents merge anything in production:

- **Field values you did not select.** Only one value survives per field. A description written on the losing case is gone unless somebody copies it first.

- **Feed history.** The chronological record of what happened on the losing case, including internal discussion, does not reliably carry across.

- **The case number.** A customer referencing the old number in an email gets nothing from a search.

- **Milestone records.** SLA attainment data attached to the losing case is attainment data you can no longer report on.

- **Anything a report counted.** Volume, first response and resolution metrics for closed periods change retrospectively.

## Merge is irreversible, so gate it

There is no undo. Restrict the ability to merge cases to team leads rather than every agent, and write down the rule for when it applies.

A rule that works: merge only cases raised by the same contact about the same incident where neither has customer-visible correspondence beyond the acknowledgement. Everything else gets linked, not merged.

## Parent and child cases

Case has a Parent Case field, and it creates a hierarchy you can view from the record. This is the right tool far more often than merge.

Two patterns account for most legitimate use:

**One incident, many reporters.** An outage generates forty cases. Create one parent for the incident, link the forty as children, work the parent, and communicate out to the children. Nobody loses their own case and every reporter still gets an update against their own case number.

Both keep every case as a real record with its own history, SLA and reporting. That is the whole advantage over merge.

## Closing the children

Salesforce does not cascade a close from parent to children for you. Build it, because otherwise the forty cases from the outage sit open forever and your backlog figure is fiction.

A record-triggered flow on the parent that fires when it closes, finds the children and closes them with a standard resolution works. Send the customer-facing email from the same flow so each reporter hears about it on their own case.

```apex
SELECT Id, CaseNumber, Status, ContactId
FROM Case
WHERE ParentId = :parentCaseId AND IsClosed = false
```

## Related cases without hierarchy

Sometimes two cases are related without one owning the other: a billing query and a service complaint from the same customer, where the resolution of one affects the other. A parent relationship is the wrong shape for that, because it implies the child is part of the parent.

A lookup field or a junction object is honest about the relationship being lateral. It is more work and it does not pretend one case is subordinate to the other.

## Duplicate prevention beats merge

The best merge is the one you never do. Duplicate rules on Case, matching on contact plus subject similarity within a short window, catch the “customer emailed twice” pattern at creation.

Merging is a last resort. Preventing the duplicate in the first place is the subject of [duplicate rules and matching rules](https://trailassembly.com/salesforce-duplicate-rules/).

## Frequently asked

**Can I merge cases from different accounts?** The interface will let you attempt merges that make no business sense. Add your own guardrails rather than relying on the tool to stop you.

**Does merge notify the customer?** No. If a customer has correspondence on a case that is about to lose, email them the new case number first.

**How deep can a case hierarchy go?** Deeper than you should use. Two levels is almost always right. Three means somebody is modelling a project in the case object.

---

Source: https://trailassembly.com/case-merge-and-related-cases/
Trail Assembly — independent Salesforce write-ups.