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”
Linear issue, quotes attached
insight report in NotionStep 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:
- Launches from a Global Action on the Account or Opportunity page layout
- Pre-fills
Requested byand links the new junction record to the account in context automatically - Asks for just two fields: request detail, and product area
- 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.
How Fenwick Analytics runs it
Fenwick Analytics sells data-infra tooling into mid-market ops teams, a 40-person company where RevOps sits close enough to sales to hear every ask directly. Renata Osei, who runs that team, built this exact object after the same request showed up on two calls in one week with no record of either.
Renata, in the #renewals Slack channel: Just added a Feature Request flow to the Account page. Click the lightning bolt, two fields, done. If a prospect or customer asks for something we don't have, log it there instead of the deal notes.
Devon, AE: Does it dedupe automatically or do I need to check first?
Renata: Not automatic. Search by product area first. If it's already there, just add your account to the junction instead of creating a new one. Takes ten extra seconds.
Three weeks in, the Feature_Request__c list view showed a scheduling-permissions request attached to four accounts, two of them in active renewal conversations. That report is what got it onto the roadmap; nobody had to remember which calls it came up on.
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. Devon's question above 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.
That's the gap Modem is built for. 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 attaches account and opportunity context synced from Salesforce (read-only; it doesn't write back into your org), so a request shows up already connected to 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.
