How to Stop the Same Feature Request from Becoming Five Separate Salesforce Cases
The fix is to stop asking whether two case records match and start asking whether two requests mean the same thing, no matter which case number either one landed under. Group by meaning instead of by record, and five accounts describing one gap in five different wordings stop looking like five separate asks. Case Merge doesn't do that, and it isn't built to. Salesforce's merge tool combines up to three cases at a time, and it works well for the situation it was designed for, one contact filing the same case twice, or an agent's request duplicating one that's already open. It does nothing for five different accounts each opening their own case with their own wording for what turns out to be one feature request, because nothing in Salesforce is looking across cases for a shared idea. It's looking for cases that are literally, provably the same record.
That gap has a name in the Salesforce admin community. Salesforce Ben calls it channel thrashing, when one customer's problem generates cases across email, phone, and community in parallel. The five-case version of the same problem is the account-side variant, five different customers surfacing one product gap, and it's arguably worse, because each case reads as an isolated, single-customer ask instead of five votes for the same thing.
“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 NotionCase Merge, mechanically: a three-case ceiling and no matching layer
Case Merge lives in Lightning Experience, either from a case list view (select up to three cases and merge) or from a single case record, where a Merge Cases button lets you search for another case by number or subject and pull it in, per Salesforce's own documentation. The merge action requires delete permission on the Case object, which Salesforce Ben's writeup flags as a permission most admins are reluctant to hand out broadly.
The bigger limit for this problem isn't the count, though three would still fall short of five. It's that merge assumes you've already found the duplicates. There's no matching-rule layer on the Case object the way Salesforce offers for Leads and Contacts, so nothing surfaces "these three cases are probably about the same thing" on its own. An agent has to notice the overlap first, usually by recognizing similar phrasing while working a queue, and five accounts describing one gap in five different ways is exactly the pattern that phrasing-based recognition misses.
Why the same request looks like five different requests
Case subjects are free text, written by whoever's frustrated enough to file the case. The same underlying gap comes in as:
- "Can we get bulk export from the dashboard?"
- "Need a way to pull all records at once instead of one at a time"
- "Your competitor lets us download everything in one click, why can't we"
A keyword search on "export" catches the first two if someone thinks to run it. It misses the third entirely, and it misses anything filed under a case type of "Feature Request" versus one filed as "Bug" by a customer who considers the missing capability a defect. Case Merge, and any manual dedupe process built around it, depends on someone recognizing that these are the same ask before doing anything about it. At low volume, one support lead reading every case can hold that pattern in their head. Past a few dozen cases a month across a handful of product areas, they can't.
How Greer Malone caught it at Winslow Fleet Systems
Winslow Fleet Systems sells telematics software to trucking and delivery fleets, and runs support through Salesforce Service Cloud, cases coming in from fleet dispatchers at each customer account. Greer Malone manages support operations there, and reviews the open case queue every morning.
Greer, in a note to the product team: I've got five open cases right now that are all some version of "let us export the driver break-time report as CSV instead of just viewing it on screen." Five different accounts, five different subject lines. None of them reference each other, so if I hadn't happened to read all five this week we'd have shipped nothing and each dispatcher would think we ignored them.
Product lead: How did you catch it if the subjects don't match?
Greer: I didn't, not systematically. I read case bodies most mornings because the subjects lie. It's not something I can hand off to someone newer on the team and expect the same catch rate.
Greer's fix for that week was a shared spreadsheet, a running list of "known asks" with case numbers linked underneath each one, checked before closing any case that smelled like a feature request. It worked, in the sense that the five cases got connected before the sixth arrived. It also depended entirely on Greer personally reading every case body, which is the same single point of failure Case Merge has, just moved from Salesforce's merge tool to a spreadsheet.
Three ways Greer's spreadsheet runs out of road
The spreadsheet-and-vigilance approach breaks down for reasons that show up in order as volume grows:
- It requires one person to read everything. The moment case volume outgrows what Greer or an equivalent can personally review each morning, dedupe accuracy drops with no warning that it's dropping.
- It only sees Salesforce. A fleet customer who mentions the same export gap on a renewal call, or in a Slack Connect channel with their account manager, never reaches the spreadsheet, because the spreadsheet is fed by reading cases, not by reading everywhere the account talks to Winslow.
- The count resets with every new person on the team. A new support hire doesn't inherit Greer's memory of which five cases already got linked; they inherit the spreadsheet, if they know to check it and it's current.
None of this means Case Merge or manual review is a bad starting point. For a small support team fielding a case or two a week that might be a duplicate, an admin comparing case bodies by hand is proportional effort. It stops being proportional once the same request is arriving from multiple accounts through multiple channels in the same month, because that's exactly the pattern that depends on someone remembering everything they've read, and nobody does that reliably at scale.
This is roughly the ceiling manual tracking hits, and it's the gap a dedicated tool is built to close. Modem groups requests from Slack, Zendesk, Gong calls, and the other places an account actually talks to a company like Winslow, by what a message means rather than by shared keywords, so "export the report" and "download everything in one click" land as the same topic even with zero words in common. Salesforce itself isn't one of the channels feeding that grouping. The Salesforce integration syncs accounts, contacts, opportunities, and users, not case content, so it attaches account and deal context to a topic instead of pulling case text into it. In practice that means a topic built from a Slack Connect thread or a Gong call shows which accounts and opportunities sit behind it, including the mid-renewal ones you'd otherwise only catch by cross-referencing case numbers by hand. If an ask only ever shows up inside Salesforce cases with no echo in another channel, the agent can still run a read-only Salesforce search for it on request, which is a lookup rather than the automatic clustering a Slack or Zendesk topic gets. We build Modem, so read this section as a vendor with a stake in the outcome, not a neutral referee. For the manual build we're describing an alternative to here, see how to track feature requests natively in Salesforce, and for tools that connect feedback more broadly to Salesforce account data, the best tools to connect customer feedback to Salesforce.
Make the duplicate check a required step, not a habit
Pick one product area and give the check a fixed shape. Before closing any case with a feature ask in it, search a shared doc for existing asks by what the request means, not by matching words. Log the case number and a one-line summary against a match, or start a new entry if there's no match, and do the search from the doc rather than from memory. That takes under a minute per case, and unlike a habit built on one person's attention, it holds up when that person is out sick, promoted, or simply has forty cases open instead of five.
