How to track feature requests natively in Salesforce without a third-party tool

Yes, but there's no shortcut around building it. Salesforce doesn't ship a feature-request object the way it ships Case or Opportunity, so "tracking feature requests in Salesforce" always means a custom object, a way to attach it to the account asking, and enough automation that reps actually fill it in. Salesforce's own Admins blog treats this as a build-it-yourself problem too: its guide to request-management apps walks through custom objects, screen flows, and approval processes for exactly this kind of internal intake, because there's nothing native to point at instead.

The build itself is a weekend of admin work, not a project. Three pieces make it hold up past the first month: a custom object with a real status model, a junction object so the same request can attach to more than one account without duplicating records, and a Flow that lets a rep log a request in ten seconds from the account they're already looking at. Skip any one of the three and the object either fills with duplicates or stops getting used.

“we need SSO before rollout”

“any update on single sign-on?”

“SSO came up twice on this call”

↓ classified + deduped into

SSO requests

8 accounts asking · quotes kept

filesLinear issue, quotes attached

writesinsight report in Notion

answersthe Modem agent

Step 1: build the custom object with a status model, not just a text field

Create Feature_Request__c with fields that support triage, not just a description:

• Request detail (long text) capturing what was asked, in the customer's words if possible
• Status (picklist): New, Under Review, Planned, Shipped, Declined
• Product area (picklist): 8 to 12 values, matching however your team already talks about the product
• Source (picklist): Sales call, Support case, Renewal, QBR, Other
• Requested by (lookup to Contact)

Resist adding a priority field here. Priority belongs to your product team's process, not to whatever the closing rep felt in the moment; a Status of Under Review is enough to signal "someone needs to weigh in."

Step 2: add a junction object so one request can dedupe across accounts

A single-object setup breaks the first time two accounts ask for the same thing, because there's no way to say "this is the same request" without duplicating the record or awkwardly listing account names in a text field. Savio's writeup of the manual approach recommends exactly this fix: a junction object relating the feature request to the account (or opportunity) asking for it, so the same Feature_Request__c record can carry multiple accounts and a running count.

Build Account_Feature_Request__c as a junction with a master-detail (or lookup) relationship to both Feature_Request__c and Account, plus a Notes field for what that specific account said. The count of related junction records is your demand signal. "Captured by 6 accounts" is a report your product team can act on, and rerunning that report each week costs nothing once the object exists.

Step 3: build a Screen Flow so logging a request takes ten seconds

The object above is useless if reps have to navigate to a new-record page and fill in five fields from memory. The Admins blog's pattern applies directly here: a screen flow launched from a Global Action, available from the utility bar on the record the rep is already viewing. Build a Flow that:

1. Launches from a Global Action on the Account or Opportunity page layout
2. Pre-fills Requested by and links the new junction record to the account in context automatically
3. Asks for just two fields: request detail, and product area
4. On submit, posts a Chatter note on the account so the CSM sees it without checking the object directly

Two fields and one click is the difference between a system reps use in the moment and one they mean to backfill later and never do.

Where this stops covering the requests you actually get

The object works precisely as well as your reps' discipline, and it only ever sees what gets typed into Salesforce. Two limits show up fast:

• It only catches Salesforce-originated asks. The same feature request that comes in through a support ticket, a Slack Connect channel, or an unrecorded customer call never reaches the object, because nobody opens Salesforce to log it from those channels.
• Dedupe is manual and depends on someone searching first. Asking whether a request already exists, and answering it from memory, is the failure mode. Skip the search step once and you have two records for the same request, splitting the count that was supposed to prove demand.

For a single team whose requests genuinely all arrive through Salesforce-adjacent conversations (sales calls, renewals, QBRs), this setup is enough, and there's no reason to add a tool on top of it. It stops being enough the moment requests are arriving in more than one place, which for most companies is most of the time. A request a customer mentions to their AE on a call is also showing up as a Zendesk ticket from someone else at the same account, or in a Slack Connect channel, and none of those get typed into Feature_Request__c by anyone.

Modem is built for the requests that never make it into that field. Modem captures feature requests as they arrive in Slack, Zendesk, Gong calls, and the rest of your support and conversation tools, dedupes the same ask across all of them automatically, and syncs account and opportunity context from Salesforce (read-only; it doesn't write back into your org) that the agent can query, so you can look up the account asking without a rep having to remember to log it. Modem is our product, which is a reason to read that comparison with a skeptical eye rather than take our word for it. If your team's requests genuinely all arrive through Salesforce, nothing above argues for tearing out what you just built. For related reading on the tools that connect feedback to CRM data more broadly, see the best tools to connect customer feedback to Salesforce, and for what happens after a request is captured, how to close the feedback loop with customers.

What to build first

If you're starting from nothing: build Feature_Request__c with the five fields above and Account_Feature_Request__c alongside it, then get the Screen Flow onto the Account page before you ask anyone to use the system. All three exist for a reason; leave one out and you'll be rebuilding it the week the first duplicate shows up. The flow is what determines whether this becomes real data or an object with three records in it by December.