Please tell us what we can do to make Featurebase the best product for you.
Checkbox form field: option to be checked by default
Let admins set a Checkbox custom field on the request form to start checked. Teams with DPA or consent text want the box pre-selected, and users can still untick it. Today the Checkbox field only has "Require checking" (the user must tick it before submitting); it always starts unchecked.
GitHub integration: board-level sync rules and per-board repository routing
Bring the GitHub integration in line with Linear and Jira: let each Featurebase board (category) route to its own GitHub repository, and let sync rules be scoped per board. How it works today Automatic push uses one repository for the whole workspace. It can be limited to selected categories, but every pushed post lands in that single repository. GitHub sync rules map a GitHub issue state to a Featurebase status. A rule has no board field and no repository field, so rules cannot be scoped by board or by repo. The repository is only selectable at push time, on a manual push. A post can end up linked to issues in several repositories that way, one push at a time. One GitHub App installation per workspace. Requested behaviour A repository field and a board field on GitHub sync rules, so each board can drive its own repository and its own status mapping. Automatic push that resolves the target repository from the post's board instead of from one global setting. Same shape as Configure Linear integration Sync Rules per board and Jira integration sync rules with multiple projects, both already shipped. Why it matters Raised by a prospect running roughly 15 products, each with its own engineering team and its own repository. Without board-to-repository routing, only one team gets hands-off automatic sync and every other team has to push manually, or the company has to split into separate Featurebase workspaces purely to work around the integration. Related: Support for multiple GitHub organization integration, Advanced GitHub Integration Mapping (Title, Body, Board to Labels).
Category default blocks public visibility for individual requests
With Category access = Everyone and Default request visibility = Author only, the individual request dropdown offers only Author only and Internal. It does not offer Everyone. The default should apply to new requests. The team should still be able to make one request public without changing the default. The default should apply to new requests. The team should still be able to make one request public without changing the default.
Filter a post's voters by company attributes
I want to filter the voters of a single post by company attributes such as industry or company size, directly in Featurebase. Today the only option is exporting the voter list to CSV from the post and then filtering it in Sheets or Excel. Product research teams pick voters for discovery calls and beta tests every week (for example only construction or cleaning companies out of 300 voters), so this manual step slows them down.
Manage Request prioritization, visibility, and status updates through API and MCP
Read and update Impact ratings and Value/Effort scores through the API and MCP. Include the importance, urgency, and frequency ratings used to assess customer demand. Also allow changing whether an existing Request is internal or hidden from the Feedback Portal. This would let teams automate prioritization and control which Requests are shared with customers. Also support publishing custom Request status updates through the API and MCP, with formatted text, links, and images. Allow sending an update when changing a Request's status or for its current status, with an option to notify Requesters. The message should appear as the same pinned, status-labelled update used in the dashboard and be included in the status-update notification. Currently, the public API and MCP can change a status and send the default email, or create a regular comment, but cannot publish a custom status update. This prevents teams and AI agents from completing the full update workflow.
Expand messenger input options
Add more input options for users in the messenger, such as voice input and the screenshot tool currently available in the feedback widget.
Allow adding a URL to form fields for T&C
Add support for including a URL (e.g., a link to terms and conditions) in the checkbox form field.
Manage workspace settings through API and MCP
Create, edit, and delete Request labels, categories, statuses, and form-field definitions through the API and MCP, including field options and required-field settings. This would let teams and AI agents set up and maintain their workspace configuration without repeating the setup manually in the dashboard.
Allow request-level triage scores without a customer
Let teams set and edit Usage, Urgency, and Importance directly on a request, without attaching the scores to a customer. This supports feedback collected anonymously or from groups where attaching a direct user might not be feasible.
Improve visual separation on feedback board
Increase the visual separation between feedback requests in the list, for example with clearer borders and a hover shadow, and restore stronger text contrast for the header text that became lighter after the redesign. The current low-contrast styling makes the list hard to scan and feel messy compared to the previous design.
Export banner viewer data for cross-referencing purchases
Provide an export feature for banner statistics that extracts the users who interacted with or viewed a banner, so the data can be transferred to an external database or file. Copying data manually is not viable at the scale of thousands of tracked users. The goal is to correlate banner viewers with purchase data to measure conversion after a communication campaign.
Move or collapse Autopilot so the full Request can be copied in one selection
Autopilot sits between the title and body, splitting the content into two selection areas. Teams copying a full Request need two steps instead of one. It would be great if you could place Autopilot after the body, or allow it to collapse.
Requests counter missing from dashboard
The request counter that used to appear on the left side of the Requests screen is no longer displayed. Restore the counter so the number of requests is visible without extra steps, or clarify where it can be re-enabled.
Show Create new view button without hover in Requests
Make the Create new view button in the Requests tab visible without requiring a hover. The control is currently hidden until the cursor is over the Categories tab area, so users do not realize it exists.
Request visibility control does not account for stored company access
The visibility control ignores stored company access when showing “Visible on portal” or “Author only.” As a result, public access can remain blocked, or company users can retain access despite the author-only label. Selecting “Visible on portal” does not clear company restrictions. Selecting “Author only,” then “Visible on portal,” clears them.
Sync Private Comments to Jira Tickets
I would like the ability to send private comments from Featurebase posts to the linked Jira tickets. This would help consolidate all relevant internal communication within Jira.
Eligible users cannot access segment-restricted feedback boards
Some users receive a “no access” message after verifying their email, even though they match a segment allowed to access the board. Segment membership updates can be delayed, preventing eligible users from receiving access.
Manage and create Roadmaps through API and MCP
Create and manage Roadmaps through the API and MCP, including their columns, filters, and visibility. This would let teams and AI agents configure Roadmaps and keep them up to date from their own tools without manually editing each Roadmap in the dashboard.
Set conversation attributes when creating a ticket
Allow conversation attributes to be chosen at the moment a new ticket is created, rather than only after the ticket exists. Currently the ticket must be created first and then located again to fill in the attributes, which doubles the work when the information is already known at creation time. The creation dialog (see attached screenshot of the Create new ticket view) offers no place for these attributes even though there is room for them. The selection must expose the existing conversation attributes so the values link to the current attribute set; adding a separate new value that does not integrate with the existing attributes would not solve the problem.
Add 'currently viewing' to feedback posts
I am requesting a feature to display who is currently viewing a feedback post within the feedback module. This functionality is currently available in the Support inbox but not for feedback posts. Our team experiences duplicate effort, with approximately 5 out of 400 weekly feedback posts last week receiving similar replies from multiple agents. This leads to wasted agent time and a suboptimal user experience. Implementing a 'currently viewing' indicator would allow agents to avoid posts being actively worked on.