How to Merge Duplicate Salesforce Cases from One Customer About the Same Bug
Salesforce's Case Merge does exactly this, up to a point. Filter the case list view by Account Name so all three cases surface regardless of which contact filed each one, select up to three of them, and merge. You pick which field values survive, and the emails, comments, and attachments from all three cases land on whichever one you keep as the master. Nothing in the thread gets lost in the merge itself.
The point where it gets harder is after. Merge deletes the two non-master cases to the Recycle Bin, and the moment that happens, any contact who replies to their original case's email confirmation lands on a case that no longer exists, which Salesforce turns into a brand-new case rather than a comment on your merged one. Three cases about one bug can quietly become four, through the exact channel you just cleaned up.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionFind all three cases by account, not by subject line
Case Merge has no idea your three cases are related unless you tell it. Two of its entry points depend on you already knowing the case number or matching subject text, which is a bad bet when three different contacts wrote three different descriptions of the same bug. The reliable path is the Account.
- Open the Account record for the customer and look at its related Cases list, or go to a Case list view and filter
Account Name equals <customer>. Every open case tied to that account shows up regardless of who filed it or what they called it. - From that filtered list, select the cases you believe describe the same bug, up to three at a time, and click Merge Cases.
- Salesforce shows you the field values from each case side by side. Pick which Subject, Priority, and custom field values carry forward to the master.
- Confirm. The master case now carries the combined case feed, meaning the emails, internal comments, and attachments from all three original cases are visible in one timeline, and any child cases attached to the losing records get re-parented to the master automatically.
This is the mechanism Salesforce documents for merging cases, and it works the same way whether the duplicates came from one contact filing twice or three different people at the same account. The account filter is what makes it usable for the second case: it doesn't care who filed what, only which account they belong to.
What actually happens to the two cases you don't keep
The merge doesn't delete data, but it does delete records. According to Salesforce Ben's breakdown of the feature, the losing cases go to the Recycle Bin, and while they're technically restorable, restoring one "will not move any of the above back to the original." The feed entries, related records, and re-parented child cases stay with the master. Practically, treat the merge as final once you've confirmed it.
The merge button itself requires delete permission on the Case object, which is a broader grant than most admins want to hand every support rep. On a small team it's manageable; the same Salesforce Ben piece flags it as something larger orgs tend to restrict to team leads, which means whoever's doing the merging needs that permission provisioned ahead of time, not discovered mid-incident.
How Coral Hutchins caught it at Farrow Bay
Farrow Bay sells scheduling and recall-reminder software to veterinary practices, and runs support through Salesforce Service Cloud. Coral Hutchins handles case triage there, working a queue that spans dozens of independent practices and a handful of multi-location groups.
On a Tuesday, a case came in from the front desk at Alder Creek Veterinary Group:
Case #00341, filed by front desk lead: Recall reminder texts stopped going out to clients this week. We've had three people call in about missed rabies boosters.
Coral answered it as an isolated report and moved on. Two days later, a second case landed:
Case #00358, filed by the practice's office manager: Something's wrong with automated reminders. None of our recall texts have sent since Monday.
Bastian Louw, Alder Creek's operations lead, in Case #00362: Just checking in on this. Our clients aren't getting recall texts and we're getting complaints. Is this being worked?
Three cases, three contacts, one account, one bug. Coral only noticed the overlap because she happened to recognize the account name on the third case. She filtered Alder Creek's case list by account, confirmed all three described the same missed window of failed sends, and merged them, keeping #00341 as the master since it had the most detail on timing. The combined feed now showed the full picture: three complaints, one root cause, and a timeline of exactly when the texts had stopped.
A week later, Bastian replied to the confirmation email for his original case, #00362, to ask if there was an update. Because #00362 had been merged away, his reply created case #00379 instead of landing on the master. Coral caught it the same day, but it was the same manual account check that had caught the first three, run again.
Why an entire AppExchange category exists for this
Case Merge assumes a human has already spotted the duplicates and can act on them one merge at a time. That gap is well known enough that third-party apps exist specifically to close it. Auto Merge Duplicate Cases, a free AppExchange listing from Deligence Technologies, matches cases on subject line, sender email, and description, then merges them automatically and marks the losing case "Merged as Duplicate and Closed." Its own listing pitches "merge multiple cases at a time" as the improvement over the native three-case, manual-selection flow.
That an app exists to automate exactly this step is the tell: enough Salesforce admins hit the same wall Coral did that someone built and published a fix for it. It's also a narrower fix than it looks. Matching on subject and sender email still misses the Alder Creek pattern, where three different contacts wrote three differently worded subjects. It would have caught two textually similar filings from the same person; it would not have connected Bastian's case to the front desk's.
Where manual merge stops working
Merge and its automated cousins share the same ceiling: they only look inside Salesforce cases. The #00379 problem is the sharpest example. Once #00362 went to the Recycle Bin, nothing in Salesforce was watching for a reply to its confirmation email, so Bastian's follow-up had no merged case left to land on and became a new one instead. Deligence's matching rules do not catch it either, since #00379 arrives as a fresh case with no shared subject or sender history left to match against. The same blind spot caught the Slack Connect message Bastian's team sent their account manager about the outage, days before the third case was even filed. It never became a Salesforce case, so Case Merge and Deligence's matching rules never had a chance to see it.
Modem is built to watch the channels a support and account team actually use, not just the case record those channels eventually produce. Forward the support inbox a reply like Bastian's lands in to the unique address Modem's email integration provides, and add the Slack Connect channel Farrow Bay already shares with the account, and Modem sees both messages the moment they arrive, independent of what Salesforce does with any case that came before them. Because Modem groups reports by what they describe rather than by case number or subject line, Bastian's reply and the Slack Connect message about the same outage match to one topic instead of one becoming orphaned case #00379 and the other going unread. The Salesforce integration plays a narrower, complementary part here. It syncs accounts, contacts, and opportunities, not case content, so once a message lands in that topic, it's the Salesforce sync that ties it to Alder Creek and to Bastian's contact record, not a case number a rep has to notice matches two others.
We build Modem, so weigh that recommendation as coming from a vendor with a stake in the outcome, not a neutral party. Below the volume where a bug crosses contacts and channels in the same week, the account-filtered merge above is the right amount of process, and reaching for more tooling before you hit that point is wasted effort. For the manual side of tracking requests inside Salesforce itself, see how to track feature requests natively in Salesforce. For the sibling problem of five accounts describing one gap in five different ways rather than three contacts at one account, see how to stop the same feature request from becoming five separate Salesforce cases.
The smallest version you can start this week
Before merging any case with a feature request or bug in it, filter that account's case list first, not just the one case in front of you. If a second or third case turns up, merge them from the list view, note in the master which contacts were affected, and check back on any merged case's email thread a week later for stray replies. That single habit catches most of what Coral caught by accident, and it costs about the same minute the account filter already takes.
