How Featurebase Forwards Feedback to Issue Trackers: The Threshold That Never Fired

There is a post on Featurebase’s own feedback board called “Upvote threshold for forwarding posts to issue management integrations.” It was filed by Bruno from Featurebase about three years ago. 200 people have upvoted it. Its status is Planned.

We were building the same feature for Usero this week, a rule that acts when enough people ask for the same thing. Before writing any code, I wanted to see how the people who filed this request handle forwarding today.

So we spent the evening inside a live Featurebase workspace on the Free plan, plus their help center and public pricing page. Where the paywall stopped us from clicking something ourselves, the claim comes from their docs, and I have tried to keep the two apart.

The request that started it

The post itself is short. Bruno’s example: “with the Clickup integration, there could be an option to set a limit of 10 upvotes for the post to be pushed to Clickup.” That is the whole idea. Once demand crosses the line, the ticket files itself.

The comment thread is a small time capsule. Mamane Bello, almost three years ago: “also have some sort of triggers for bugs to be pushed to Jira for instance as they come... because they are bugs and need to be attempted to immediately.” Patrik B, nine months ago: “This! But for Linear :P”. The activity feed has exactly one entry: Markus from Featurebase changed the status to Planned, about one year ago. Three years, 200 votes, one status change.

I do not read this as laziness. Every team, ours included, has a Planned column where reasonable ideas go to wait. What caught my attention is that Featurebase builds a prioritization tool, and their most upvoted integrations request has been losing at prioritization for three years. If it can happen there, it can happen on anyone’s board.

How forwarding works today

Without the threshold, Featurebase gives you two modes. Mode one is a toggle in each integration’s settings: “Automatically push new posts.” Every new post, no filter by board, tag, vote count, or anything else. On a board with real volume that is a firehose into your tracker, so I suspect almost nobody runs it. Mode two is manual: open a post, click the tracker icon in the top-right corner, create a new issue or link an existing one. One post at a time.

What happens after the link is made is the good part. Statuses sync both directions, per-board rules map Featurebase statuses to tracker states, and upvoters can get emailed when the status changes. Linear gets the deepest treatment: push posts as issues or projects, pull Linear issues back in to collect feedback on them, multiple teams, due-date sync. The close-the-loop story is coherent and better specified than most of the category.

The whole path is paid, though. Issue management integrations (Linear, Jira, ClickUp, GitHub) start on the Growth plan at $29 per seat per month, $348 a year for one seat billed yearly. Azure DevOps is Enterprise, $99 per seat. And the Free plan does not always tell you: the integrations grid showed us Connect buttons on GitHub, Linear, and ClickUp, and GitHub’s install screen loaded happily before anything mentioned a plan. The gate is somewhere after the OAuth handshake, not before it.

Could you build the threshold yourself?

My first thought was webhooks. The documented events are posts, comments, and status updates. No vote-count event, no threshold event. Zapier’s card in their settings is honest about its limits: “Use new posts and comments as triggers.” So neither escape hatch can say “this post crossed 10 upvotes” without you polling their API on your own server. Both are Growth-gated too, $29 per seat, the same tier as the integrations themselves.

I also walked the full settings tree looking for any automations surface, a rules builder, a “when X then Y” screen, anything. There is none. The closest things are the per-integration status sync rules and Macros, which are canned support replies. Featurebase measures demand richly (upvotes, importance votes, customer spend on the author panel) and none of that signal can trigger an action. It is a reporting output only.

(One aside from the walk: their API docs site at docs.featurebase.app was returning “Documentation unavailable” the whole evening, so the webhook event list had to be confirmed from secondary sources. And the most-upvoted integrations request on their board still carries a “this is test comment reply” from their own test data. Small things, but telling.)

The ceiling: an issue, never a fix

The part of the teardown that surprised me was on GitHub’s side, not Featurebase’s. Connecting the integration walks you into GitHub’s app install screen, and the requested permissions are two lines: read access to metadata, read and write access to issues.

No pull request permission, no repository contents permission. The app cannot read code and cannot write it. So even if the threshold shipped tomorrow, on the $99 plan, with every condition anyone asked for, the best possible output of the pipeline is a filed issue. A well-linked, status-synced backlog item that a human still has to pick up and build. The threshold moves the bottleneck from “someone notices the votes” to “someone picks up the ticket.” It does not remove it.

One more post on their board makes the stakes concrete. William Patterson, six months ago, asking for Jira tickets to be created automatically on status change: “This is a key feature for our workflow and a major reason we upgraded our Featurebase package.” A customer paid for conditional forwarding that is not there. His post has 1 upvote and sits at In Review.

What we built the same night

Usero’s wedge is turning feedback into a draft pull request, so we already had the expensive parts: clusters that group differently-worded reports of the same problem, a GitHub connection with code access, and the AI PR pipeline. The threshold was the missing trigger, and Bruno’s three-year-old spec was sitting right there. We shipped it before the evening ended.

It is a per-project setting, off by default: pick a number of unique requesters, and when a feedback cluster crosses it, Usero drafts a PR against your repo. Requesters, not votes. Upvoters on the linked board post are merged in and deduplicated against the people who submitted feedback directly, so one person who submitted twice and also upvoted counts once. A sweep checks every cluster every 15 minutes.

Each cluster fires at most once. When it does, the cluster gets stamped and wears an “Auto-drafted · demand threshold” badge, so six months later nobody wonders where that PR came from. The draft goes through the same GitHub flow as a manually requested PR: a branch with a first pass at the change, waiting for a human. Nothing merges on its own, on purpose. I think the reason nobody runs “push all new posts” toggles is that they are unsafe. A threshold plus a draft you can close without consequence is the version people will leave switched on.

What we would steal from them

This series is about learning from products we respect, and two Featurebase decisions are on our list now. First, status-change emails to upvoters. Their best-loved behavior is that when a linked issue moves, everyone who voted hears about it, and our version of closing the loop should be at least that good: when the drafted PR merges, every requester in the cluster should be told what shipped. Second, Mamane Bello’s comment from three years ago is a better spec than a raw count: bugs should fire at a lower bar than feature requests. Post type, board, and requester revenue as conditions are where we want to take the threshold next.

The limits of ours

Honesty about our own edges, since this post spends a lot of words on someone else’s. Counting unique requesters depends on identity: fully anonymous feedback cannot be deduplicated, so a cluster full of it can over- or under-count, and the number is a strong estimate rather than a census. One shot per cluster means a cluster that keeps growing after its PR will not spawn another, by design, but you may disagree with that call. The PR is a first pass a human reviews, sometimes it will be wrong. And the feature ships off by default, because drafting a PR costs real compute and we would rather you turn on the spend than discover it.

We also could not see everything on their side. The Growth-plan connected state, the rules editor, and the post-detail tracker icon are documented rather than observed, because GitHub’s re-auth wall stopped our install and we were not going to pay $29 to finish a teardown. If you run Featurebase on Growth and any of this reads wrong, tell me and I will correct it.

The threshold request is a good idea. It was a good idea three years ago when Bruno filed it. If Featurebase ships it next quarter, their customers get a better product, and the ceiling is still a filed issue. Ours ends in a diff.

We looked at how Featurebase scores demand in the prioritization matrix study. Or try Usero free and set a threshold on your own feedback.

Frequently Asked Questions