How to Weigh a Feature Request in Salesforce by the ARR of the Accounts Asking For It
"Five people asked for this" and "five people worth $2M in ARR asked for this" are different facts, and Salesforce usually already has enough on file to tell you which one you're looking at. The gap isn't missing data. It's that the ask and the account's value sit on two objects that were never built to talk to each other: the ask lives on a Case, a Chatter note, or a custom field, and the dollar figure lives on the Account or on a closed Opportunity. Nothing joins them by default.
You close that gap with one report, not a new system. Salesforce's report engine can already pull fields from a related object one hop away, so a report built on whatever holds the ask can carry the account's revenue field alongside it, grouped by account instead of by individual record. The work is building that report once and keeping the source fields populated. From there, "five customers asked" and "five customers worth $2M asked" come out of the same query.
“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 out which field is actually carrying the dollar amount
Before building anything, check which field your team means by "ARR," because Salesforce ships more than one revenue-shaped field and they measure different things.
- Account.AnnualRevenue is a standard field, but it's the company's total reported revenue, not what they pay you. It usually gets populated once by a data-enrichment tool or typed in by hand during account creation, and it has no relationship to your contract.
- Opportunity.Amount is the deal value on one specific Opportunity. For a renewal or upsell Opportunity, that number lands close to ARR. For a multi-year or one-time deal, it doesn't, unless someone normalizes it first.
- A custom field on Account, something like
ARR__corCurrent_ARR__c, synced nightly from a billing system, is what most teams that have actually solved this problem end up using. If your org already has one, it's the field to report on. If it doesn't, the Amount on the active renewal Opportunity is the next best proxy, with the caveat above attached.
Confirm which one applies before you build anything downstream of it. A report that quietly sums AnnualRevenue instead of contract value will produce a number that looks confident and means nothing.
Build one report that spans the ask and the account
Once the field is settled, the report itself is a custom report type, not custom code. Salesforce's report engine lets a report combine a primary object with a related object up to four layers away and pull that related object's fields onto the same rows, per Salesforce Ben's guide to custom report types, which describes the feature as letting you "add fields onto the report from any related object." Point the primary object at wherever your team logs asks, Cases with a feature-request record type or tag, or a custom object if you've built one, add Account as the related object, and pull in the ARR field from the section above.
Filter to the specific ask you're weighing, whether that's a picklist value, a tag, or a text search on the request itself, then group by Account and set the summary to sum the ARR field. What comes out is a report row per account, not per case, with the dollar total sitting next to the account name. Save it, and running it again for the next request is a filter change, not a rebuild.
The number that will lie to you if you're not careful
Summing straight down the report rows only works if each account shows up once per ask. It won't, if the same account filed two Cases about the same request three months apart, or if the ask got logged once from a Case and again from a Chatter note on the Opportunity. Sum ARR at the row level in that situation and one account's revenue gets counted twice, quietly inflating the number about to justify a roadmap call.
The fix is grouping by Account before summing, so the report counts each account once no matter how many records it filed under that ask. If your org sees this often enough that it's worth solving upstream instead of catching in every report, the junction-object setup that dedupes requests across accounts is the fix worth building once.
Weighing one request: bulk invoice export
Talworth Freight sells dispatch and fuel-card reconciliation software to regional trucking fleets, and Noelle Osgood runs revenue operations for a 60-person team split between sales and customer success. In October, three separate Cases came in asking for the same thing: a second sign-off before a load could be cancelled, so one dispatcher couldn't cancel a paying customer's shipment by mistake.
Product's first read was that three Cases wasn't much, sitting behind twenty other requests already ranked ahead of it. Noelle pulled a report instead, a custom report type joining Case to Account, filtered to the dual-approval tag, grouped by Account, summing the Current_ARR__c field her team already synced from billing every night.
Noelle, in the #product-roadmap Slack channel: Pulled the numbers on dual-approval before we rank it again. Three cases, but two of the three accounts are Meridian Transport and Corbett Logistics, our #4 and #7 accounts by ARR. Combined that's $410K, more than the next six requests on the list put together.
Head of Product, replying: That changes the read completely. Can you rerun this for the top ten open requests so we're ranking the same way going forward?
Dual-approval moved to the next sprint. The report stayed in a shared folder, and pulling the same numbers for the next request meant changing a filter, not starting over.
The report's ceiling
The report holds up as long as three things stay true: someone tags every ask the same way on the same object, the ARR field on the account stays current, and someone remembers to rerun the report before every ranking conversation. All three get harder with volume.
- Requests don't announce themselves. A dispatcher mentioning "we keep almost cancelling loads by accident" on a support call never becomes a tagged Case unless the person on that call thinks to log it, and calls that never touch Salesforce at all, a Gong-recorded sales call, a Slack DM from a champion, don't reach the report either.
- Tagging drifts. Three people tagging the same request three different ways,
dual-approval,cancel confirmation, a sentence typed into the description, splits one ask into rows that never sum together, and nobody notices until someone reads all three by hand. - The report is pull, not push. It sits in a folder until someone remembers to open it. Past a few dozen live requests, nobody reliably does that before a prioritization call, and the loudest recent complaint wins by default again.
That's the point where teams add something that watches for the ask instead of waiting for someone to log and tag it correctly. That's the category we work in. Modem reads Salesforce accounts and opportunities alongside the calls, emails, and Slack threads where the ask itself gets said out loud, and matches every mention back to the account underneath it, ARR included, without anyone building or rerunning a report. Modem's Salesforce integration syncs accounts, contacts, opportunities, and users, not case content, so once three accounts have raised the same request, however each of them phrased it, the topic already shows which three and what they're worth. It doesn't make the prioritization call for you; it removes the report-building and re-tagging that call currently depends on. The broader version of this problem, weighting feedback by revenue across tools beyond Salesforce, is covered in the best tools to prioritize feedback by revenue.
One report to build first
Pick the ARR field your team actually trusts, AnnualRevenue almost never being the right one, build one custom report type joining your ask object to Account, and group by Account before summing. The first time a three-Case request turns out to be a $400K request once ARR is attached, ranking by raw count stops being the default anyone reaches for.
