To make a feature request form for a Notion roadmap, keep two databases: Requests, which the form writes to, and Roadmap, with one page per feature. Link each request to a roadmap feature with a relation, and a rollup counts how many people asked for it. The Notion feature request form collects the problem in the customer’s words. You decide what goes on the roadmap.
Why a feature request form needs two databases
A feature request form needs two databases because customers describe problems, while a roadmap lists features. If both live in one table, ten people asking for “export to CSV” become ten roadmap rows.
The Requests table holds every submission as written. The Roadmap table holds one page per feature you might build. A relation between them turns repeat requests into a count instead of clutter.
What to ask on a Notion feature request form
A good feature request form asks about the problem first and the solution second. The Featurebase feature request template lists the core fields: a feature title, the problem to solve, the use case, priority, the proposed solution and business impact.
For a customer-facing form, I’d cut that down to this:
| Question | Notion property type | Required |
|---|---|---|
| Yes | ||
| What are you trying to do, and what is stopping you today? | Text | Yes |
| How would you like it to work? | Text | No |
| How much does this matter to you? | Select: Low, Medium, High, Urgent | Yes |
| Plan or account type | Select | No |
The second question is Featurebase’s own wording. It gets people to describe the job instead of dictating the button. Leave business impact off the public form; that’s for your team to judge.
How to build the feature request form in Notion
Building the form takes a few minutes on desktop or web. Notion’s forms help says all members on all plans can create and use forms, and you need Full access to the database.
- Create a database called
Requestswith the properties in the table above. - Add a
Statusselect: New, Linked, Won’t do. Keep it off the form. - Select
+next to your view tabs and choose Form. Each question is connected to a property in the database. - Mark Email, the problem question and priority as required.
- Share with Anyone on the web with link for customers, or the workspace option for internal teams.
- Submit one test request and check the new row.
Notion says public respondents are automatically anonymous. Inside your workspace you can turn Anonymous responses off, and the automatic Respondent property records who submitted. Sales and support can then log requests for customers. Our guide on sharing a Notion form publicly covers the access options.
Linking requests to roadmap features
The relation is what turns a pile of requests into a roadmap signal. Create a Roadmap database with one page per feature, then add a relation from Requests to Roadmap.
Notion’s relations and rollups help explains the settings that matter here:
- Limit to 1 page. Notion lets you cap a relation at
1 page, so each request points at exactly one feature. - Show on Roadmap. Relations are one-way by default. Toggle
Show on [name of related database]so each roadmap page lists its requests. - Count the demand. In Roadmap, add a rollup on that relation with
Count all. That number is how many requests the feature has.
Notion notes that rollups can only be sorted when they output a numeric value. A count is numeric, so you can sort the roadmap by demand.
Triage once a week. Open Requests filtered to Status = New. For each row, link it to an existing roadmap page or create a new one, then set Status to Linked. A request about “sending responses to accounting” and another about “a CSV download” can both point at the same Export feature.
Notion’s forms help also says relation questions can have a maximum number of selections per response. So you could put the relation on the form and let customers pick the feature. Test that from a logged-out browser first, since the help page doesn’t say what anonymous respondents can see in a relation question.
Prioritizing with a RICE score
Request count tells you what’s popular, not what’s worth building. RICE adds the cost side.
Intercom’s RICE post scores each idea on reach, impact, confidence and effort. Reach is people per time period. Impact uses a scale of 3 for massive, 2 for high, 1 for medium, 0.5 for low and 0.25 for minimal. Confidence is 100% for high, 80% for medium and 50% for low. Effort is person-months, and because more effort is bad, it divides the total.
In the Roadmap database, add number properties for Reach, Impact, Confidence and Effort. Then add a formula property:
prop("Reach") * prop("Impact") * prop("Confidence") / prop("Effort")
Store Confidence as a percent-formatted number so the formula multiplies correctly. Your rollup count is a decent input for Reach when you have nothing better.
Request count alone should never set the roadmap. Loud customers file more requests, and the rollup can’t tell a big account from a free trial. Use the count as one input to RICE.
Showing the roadmap to customers
A public roadmap is just a shared view of the Roadmap database. A board grouped by a status such as Considering, Planned, In progress and Shipped is the simplest.
If you want dates, use a timeline. Notion’s timeline help warns that timelines only work with at least one date property containing a range of dates, otherwise nothing is plotted. Set it under Layout → Show timeline by.
Hide internal properties like RICE scores before you publish the view. Leave the request count visible. Customers like seeing that others asked too.
Limits of a native Notion feature request form
The native setup works, but three things are missing. There’s no duplicate check on submit, so triage stays manual. There’s no upvote button on the public roadmap. And conditional logic, for example to ask bug reporters different questions than feature requesters, is only on Notion’s Business and Enterprise plans. Our list of Notion form limitations has more, and bug reports usually deserve their own form; see the Notion bug report form guide.
nDBForms is one way around the plan gate. It writes each submission as a new row in your Notion database, respondents don’t need a Notion account, and it has a Notion relation question type for picking a roadmap feature on the form. Conditional logic is on Pro and works with any Notion plan. It doesn’t add voting or merge duplicates, so the rollup still does the counting. See the nDBForms templates to start from one. For broader product feedback, the Notion feedback survey template pairs well with this setup.
FAQ
Can customers submit feature requests without a Notion account?
Yes. Share the form with Anyone on the web with link and people who don’t use Notion can submit it. Their responses are anonymous, so ask for an email.
How do I stop duplicate feature requests in Notion?
You can’t block them on the form. Keep requests and roadmap features in separate databases, link each request to one feature, and count requests per feature with a rollup.
Can I show a public roadmap in Notion?
Yes. Publish a board or timeline view of the Roadmap database. A timeline needs a date property with a range of dates, or nothing is plotted.
Can the form ask different questions for bugs and feature ideas?
Only with conditional logic, which native Notion forms limit to the Business and Enterprise plans. A separate form or form builder is the workaround.