Why Doesn't Salesforce Have a Native Feature Request Tracker
No, not the way Zendesk has a feedback tab or Intercom has tag-based reporting. Salesforce ships Case for support and Opportunity for pipeline, and neither one is shaped like "someone asked for X, here's how many times, here's who." The closest native pieces are Cases (built for resolving one customer's problem, not counting a recurring ask), Feedback Management (a survey product, sold separately, with no voting or tracking mechanism), and Chatter notes on a record (freeform, unsearchable across accounts). None of them is a feature-request tracker on its own.
What Salesforce has instead is enough raw material, Case, a custom object, a Flow, that most teams end up assembling their own version. That's a real, workable path, and it's also a build, not a setting you turn on.
What Salesforce actually gives you
Three things get reached for when someone tries to make Salesforce do this job, and it's worth being specific about what each one actually is:
- Cases. A Case is a support ticket: it has a status, an owner, and a resolution. It was not built to answer "how many accounts want this," and there's no native rollup that counts semantically similar Cases as one ask.
- Feedback Management. This is Salesforce's survey product, layered onto Sales or Service Cloud as its own add-on with its own price tag. It captures structured responses and maps them back onto records like Cases or Accounts. It has no upvoting, no request queue, and no concept of a "theme" with a count attached. Salesforce Ben's writeup of Feedback Management backs up the shape of the product it describes, Survey Subject records that map responses onto Cases or Accounts, lifecycle scoring layered on top, and pricing separate from the rest of Sales or Service Cloud that runs $42,000 to $504,000 a year depending on edition. That's a survey and analytics layer, not a request-tracking one.
- Chatter. A free-text note or post on a record. It preserves the wording, but it isn't searchable the way a tagged, typed field is, and nothing rolls Chatter posts across ten accounts into one counted item.
“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 NotionSalesforce customers have asked Salesforce for this
Here's the detail that makes the gap concrete: Salesforce runs its own public request board, IdeaExchange, where customers post and discuss what they want Salesforce to build next. Sitting on that board is an idea asking Salesforce to add feature-request tracking as a native capability, the same gap this guide is about, filed by a Salesforce customer, on Salesforce's own infrastructure for collecting exactly this kind of ask. Salesforce has the pattern for a request board. It just hasn't shipped an equivalent one that a customer can turn on for their own product's requests inside Sales or Service Cloud.
The build that fills the gap, in outline
The workable native path is a custom object: something like Feature_Request__c with a status picklist, a product-area picklist, and a lookup to the account or contact who asked. Pair it with a junction object so the same request can attach to more than one account without creating duplicate records, and a Screen Flow so a rep can log a request in two fields from the record they're already on. None of that is exotic Salesforce work; it's a deliberate weekend of admin time, and we've walked through the exact fields and Flow logic in how to track feature requests natively in Salesforce without a third-party tool.
That build is real and it holds up, for the requests that actually reach Salesforce. The rest of this guide is about the part that doesn't.
How the gap showed up at Coalridge Freight
Coalridge Freight sells dispatch and load-scheduling software to regional trucking brokers, twenty-two people, support handled by two people who live in Salesforce Service Cloud all day. Denise Okafor runs that support desk. For a year, feature requests lived wherever a rep happened to type them: a line in the Case description, a Chatter comment, sometimes nothing at all if the rep just answered and closed the ticket.
The gap showed up on a Tuesday when Greg Tanaka, an account exec, was prepping for a renewal call.
Greg, in a Slack DM to Denise: Did anyone ever ask for a way to see driver ETAs on the dispatch board itself, not just the load detail page? Bridgepoint's renewal call is Thursday and I want to know if this has come up before or if it's just them.
Denise: Let me check. (pulls up Cases filtered to Bridgepoint, then searches Case comments for "ETA") I see one Case from March where a rep wrote "customer wants ETA visible on the board" in the resolution notes, closed as answered. Nothing since. But March is also before we started actually writing requests down anywhere searchable, so there could be more I can't find.
Greg: So it's at least two mentions six months apart and we genuinely don't know if that's rare or common.
Denise's search worked because she guessed the right word. A rep who'd written "dashboard" instead of "board," or logged the request only in a phone call that never became a Case, wouldn't have shown up at all. Nothing in Service Cloud counts "customers who want driver ETAs on the board" as a single number; it counts Cases, and Cases count conversations, not requests.
Where even the custom object stops covering requests
Build the object, the junction table, and the Flow, and Coalridge would fix exactly the problem in that exchange, for anything that arrives as a Salesforce Case. Two limits show up right after that:
- It only sees what lands in Salesforce. Coalridge's dispatchers also field feature requests over the phone during onboarding calls and in a shared Slack Connect channel with two of their bigger accounts. None of that reaches a Case unless a human retypes it, and retyping is exactly the step that gets skipped under load.
- Dedupe still depends on someone searching first, the way Denise had to guess "ETA" as the right keyword. A custom object with a junction table makes dedupe possible; it doesn't make it automatic.
For a team whose requests genuinely all arrive as Salesforce Cases, from accounts already in Salesforce, the custom object is the right amount of tooling and there's no reason to add anything on top. It stops being enough the moment requests are also arriving in Slack, a support tool, or on a call nobody transcribed, which for most companies with a sales or success team is most of the time.
Modem is built for that gap, and it's a different shape of tool than IdeaExchange rather than a bigger version of the same thing. It isn't a board customers post to and vote on; it's a layer that watches Slack, support tickets, and call transcripts, matches a request made on a phone call to the same request made in a Case, and attaches both to the same Salesforce account it already reads, not writes, through contacts and opportunities, without a rep having to notice the overlap or retype anything into a custom object. We build Modem, and a guide about a gap in Salesforce that ends up recommending our own product is worth testing against your own data before you take it on our word. Teams weighing more than one way to connect feedback to Salesforce data can see how the options compare in the best tools to connect customer feedback to Salesforce.
Where that leaves a Salesforce-only team
Salesforce doesn't have a native feature-request tracker, and the closest built-in pieces, Cases, Feedback Management, Chatter, weren't designed to become one. A custom object with a status field and a junction table gets you a real tracker for anything that lands in Salesforce as a Case. What it can't do on its own is catch the same request when it shows up somewhere else first, which is the point at which most teams either accept the blind spot or add something that reads across channels instead of just across Cases.
