How to link customers to feature requests in a Notion database
A Customers database, a Feature Requests database, a Relation property on Feature Requests that points back to Customers, and a Rollup property on Customers that counts how many linked rows come back the other way. Two databases, two properties, and the setup is done. Open a customer's page and you see every request they're attached to. Open a request and you see exactly who asked. Sort the Customers database by the rollup and you have a ranked list of who's asking the most, updated automatically every time someone links a new row.
That setup holds up better than people expect for a small team. What it can't do is notice when "who asked" is ambiguous, which happens more often than the tidy version suggests. A rollup counts relations, not customers, and those turn out to be different things the first time the same account ends up as two different rows.
Step 1: build the relation between the two databases
Start with two plain databases. Customers gets one row per account; Feature Requests gets one row per ask. On the Feature Requests side, add a property of type Relation, point it at Customers, and turn on "Show on Customers" when you create it. Every request you link then shows up as a linked-row list on the customer's own page, with no extra setup required. Skip that toggle and the connection only reads in one direction, from the request back to the customer, which makes the rollup in Step 2 impossible.
Notion's own documentation on relations and rollups walks through this same two-way mechanic, though its worked example links a Customers database to an Items database rather than a Feature Requests one. Link a row there, and "the customers who bought them automatically appear" back in the linked column. The behavior holds regardless of what the two databases are named. Link a Feature Requests row to a Customer row with the two-way toggle on, and it appears back on the customer's page automatically.
Step 2: add the rollup that counts
On the Customers database, add a property of type Rollup. Notion's rollup configuration asks which relation to pull from (Feature Requests), which property on those related rows to look at, and which calculation to apply, in that order. Point it at the relation itself and set the calculation to Count all. Every customer's row now shows how many requests link back to it.
A second rollup earns its place quickly. Add one more, this time pointing at a Date property on Feature Requests (when the request was logged), and set the calculation to Latest date. Notion's own list of rollup calculations includes this exact option for finding "the latest date/time in the date property for all related pages," which turns "who's asked the most" into "who's asked the most, and did we hear from them last week or last year."
Sort the Customers database by the count rollup, descending, and the QBR prep that used to mean scrolling a spreadsheet is a five-second glance.
“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 3: keep the intake rule boring
The setup only works if every new Feature Requests row gets its Customer relation filled in before anyone forgets which account asked. Make it part of the same motion as writing the request down. Title, one-line description, and the relation, all three or the row doesn't count. A request sitting with an empty relation field doesn't error out or get flagged. It just never shows up in anyone's rollup, silently, which is the least visible failure this system has.
When a rollup quietly splits across two rows
The failure mode that actually bites teams isn't the mechanism. It's duplicate Customer rows. A support ticket gets logged under the shorthand name a customer's team uses on calls. A sales contract gets logged under the full legal entity name off the paperwork. Notion has no way to know two rows like that are the same account, so it counts them as two, and the rollup splits between them.
That's what happened at a mid-size compliance-software vendor running exactly the two-database setup above. A regional building-management customer had been logged twice, once by sales under the legal entity name off the contract, once by support under the shorter name the account used on every call. Six requests had landed against the sales-created row; four more, describing overlapping asks in different words, had landed against the support-created row. Split, neither row looked especially urgent. Combined, it was the most-requested account in the database, and nobody caught it until someone sorted the Customers view for a quarterly review and noticed the same company sitting two rows apart.
Fixing it meant merging the two Customer rows by hand and reassigning the relation on every affected Feature Requests row so all ten pointed at one page. Twenty minutes, for one account, with no real way to know how many other accounts in the database were quietly split the same way without checking each one by hand.
What the rollup can and can't tell you
Be specific about the shape of the limit, because it's narrower than "Notion isn't smart enough."
- A rollup counts pages, not companies. If the same real customer exists as two Customer rows, however that happened, the count splits between them and neither number is the true one. Nothing compares row names to catch it.
- An unlinked request is invisible, not zero. A Feature Requests row with an empty relation field doesn't show up as a gap anywhere. It just doesn't contribute to any customer's count, and nothing prompts a review to notice the field was left blank.
- The count only reflects rows someone typed in. A request mentioned in a support ticket, a sales call, or a Slack thread that never got turned into a Feature Requests row isn't undercounted. It doesn't exist in this system at all.
None of that means the two-database setup is wrong for a team this size. It's the correct amount of structure for a team small enough that one person reviews the sorted list often enough to catch a duplicate row by eye.
Past a few dozen accounts, this becomes a recurring chore
Past a few dozen accounts, and a request volume that outpaces one person's ability to eyeball the sorted list every month, the split-row problem stops being a rare coincidence and starts being a recurring cleanup task, and the requests that never got typed in at all become the bigger gap of the two. That's the point where teams add a layer that resolves accounts and matches requests automatically, instead of depending on whoever's typing a name in to spell it the same way every time.
That's the category Modem works in. It reads feature requests directly out of Slack, support tickets, and recorded call transcripts, resolves the person and company behind each one to a single account record even when a name gets typed two different ways, and rolls differently-worded mentions of the same ask into one counted topic instead of one row per phrasing. Modem's Notion integration can write those counted topics into your workspace as pages or database rows, with your approval, so a Customers-and-Feature-Requests structure like the one above keeps serving as the place a team reads the numbers from, without a person carrying the job of noticing when two rows are secretly one account. We build Modem, which makes this an interested recommendation, not a neutral one. For a team small enough that someone reads the sorted list closely on a regular schedule, the plain relation-and-rollup setup above is genuinely sufficient on its own.
Related reading: how to build a feature request tracker in Notion without a template covers the single-database version of this problem, for teams that don't need a separate Customers database yet, and how to handle duplicate feature requests goes deeper on the wording side of the dedup problem this guide's relation can't touch.
The full build, in order
Build the two databases, add the Relation property with two-way sync turned on, add the Count all and Latest date rollups on Customers, and write the intake rule (title, description, relation, every time) somewhere the team will actually see it. Then put a recurring ten-minute pass on the calendar. Sort by the count rollup each time, and scan the top of the list for two rows that might be the same company. That single habit would have caught a split account like the one above the same week it happened, instead of a full quarter later.
