Please tell us what we can do to make Featurebase the best product for you.
In Progress
Manage article access and unpublishing through API and MCP
Control Help Center article visibility and audience access through the API and MCP, and unpublish live articles without deleting them. This would let teams manage access and take outdated content offline from their own tools or AI workflows.
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.
Waiting on customer
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.
In Progress
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.
Read Help Center article analytics through API and MCP
Get Help Center analytics through the API and MCP: article views, reactions, and search terms, including searches with no results. This would let teams and AI agents find articles that nobody reads, articles with negative reactions, and missing content, and then keep the Help Center up to date from their own tools.
Update Help Center settings through API and MCP
Change Help Center settings through the API and MCP, such as the display name, title, description, search placeholder, navigation links, and visibility. Today these settings can be read through the API but only changed in the dashboard. This would let teams manage their whole Help Center from their own tools or AI workflows.
In Progress
Unified knowledge management for Help Center and Fibi AI Agent
Knowledge is currently split between Help Center articles and Fibi AI Agent Training Data. They live in separate dashboards, use different content models, and cannot be searched, maintained, or automated as one source of truth. Create one Knowledge dashboard for all reusable support content, similar in concept to Intercom's Knowledge workspace. Common content types: public Help Center article, internal article, snippet, uploaded document, and external source. Choose where each item is used: Help Center, Fibi, and Copilot. An internal or Fibi-only article must never be publicly visible in the Help Center, but should be available to Fibi when answering. Unified management: search, filters, folders, bulk actions, and configurable columns for type, collection, audience, publication status, language, author, last updated date, and where the content is used. Consistent editing and lifecycle: one formatting model, drafts and publishing where relevant, source freshness, and clear ownership. Complete API and MCP coverage: list, search, create, update, delete, publish, and manage metadata for every supported content type. The goal is to stop treating public documentation and AI knowledge as separate systems. Teams should be able to create knowledge once, control who or what can use it, and maintain everything from one place.
In Progress
Disabling the Help Center should also stop article suggestions and public access
Today, "disabling" the Help Center only removes the module from the portal menu (Settings → Branding → Portal menu → Delete). The content itself stays live, so after disabling it customers still see: Articles suggested during ticket and conversation creation. Articles reachable and indexable on the public Help Center URL. The expectation is that deactivating a module makes its content and all linked functionality inactive, in one action. Requested behaviour A single workspace-level switch that takes the Help Center fully offline: no article suggestions in the Messenger or ticket forms, no public article URLs, no search-engine indexing. Apply the same principle to the other modules, so turning one off never leaves a surface still serving its content. Make the current behaviour explicit in the interface, since the existing control is a navigation change rather than a content switch. Current workarounds are partial: the Messenger Help module and article search card can be turned off individually in Settings → Support → Messenger → Customization, and articles can be restricted to Team members one at a time, which removes them from suggestions and search indexing but cannot be applied in bulk. Raised by a customer evaluating Featurebase who deactivated the Help Center and found the articles still active.
Messenger File names invisible in light/dark mode
Attachment file names in the Featurebase messenger are invisible in light/dark mode, while dark mode displays them correctly. The text color appears to conflict with the white background and is not configurable via the messenger theme settings. The default text/background contrast for attachment cards in light mode needs fixing.
Inbox view editor closes during filter selection
In a narrow browser window, clicking Add rule in Views → New view closes the editor and sidebar drawer. Resizing across the mobile breakpoint can also discard the draft. The editor should stay open during filter selection, resizing, and background clicks. Saved views should also have a keyboard-accessible Edit action.
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.
Create macros via API and MCP
Create support macros through the API and MCP so teams can set up reusable replies programmatically.
Manage Fibi custom actions via API & MCP
Create and update Fibi custom actions through the API and MCP. This would let an AI agent configure and maintain actions without having to complete each setup through the dashboard.
Automatically unsubscribe spam and blocked users
Automatically unsubscribe users who are marked as spam or blocked, so that manual user cleansing and manual unsubscribing are no longer needed to stop people who should not be receiving the information or posts anyway.
Show unsubscribes count and rate per email send
Display an unsubscribe count or unsubscribe rate for each email send. Today this number has to be tallied manually, which is inefficient and error-prone. Beyond the per-send figure, provide unsubscribe analytics per email or unsubscribe action, as well as total subscribe and unsubscribe metrics tracked over time.
Safer publishing controls for changelog updates
Enterprise teams need a safer way to publish changelog updates without slowing down drafting. They want “Show from website & widget” and “email notification” to start off by default, plus a draft-and-approval workflow where teammates can create and edit changelog updates but only designated approvers can publish them. Today, the changelog permission covers both drafting and publishing, while disabling update emails entirely is too broad. The goal is to prevent accidental public releases or customer emails while keeping the release process efficient.
Help Center-wide snapshot and versioning
Provide snapshotting or versioning for the Help Center as a whole, not just per-article history. Article-level version history already exists, but there is no way to restore the entire knowledge base after a destructive change. Broader team access combined with irreversible deletion makes an accidental mass wipe unrecoverable.
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.