Can Sentry's Feedback Widget Handle Feature Requests?
Yes. Sentry's User Feedback widget will happily accept "please add dark mode" in the same text box it accepts "the export button is broken." Nothing stops a user from typing either one. What Sentry won't do is tell them apart afterward: the widget's data model has a description, a screenshot, an optional email, and up to 60 seconds of session replay, but no field for feedback type. A crash report and a feature request land in the same inbox looking identical.
Mechanically, the widget can be used for feature requests, since it's just a text box with a submit button attached. Usefully, only if you build the classification yourself, because Sentry ships none. This guide covers how to add that layer with tags, where a small volume of widget feedback stops being manageable by hand, and what changes once it's Modem reading the same inbox instead of a person.
“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 NotionWhat the widget actually captures, and what it leaves out
The User Feedback docs describe it as a way for users to "submit feedback quickly and easily any time they encounter something that isn't working as expected," bug-first framing, even though the form itself is generic. A submission carries a free-text description, an optional screenshot, an email if the user provides one, the URL they were on, and, in JS-based SDKs, a replay clip if session replay is enabled. That's real diagnostic weight for a bug report. For a feature request, most of it is dead weight, since nobody needs a screen recording to understand "let us export as CSV."
The gap is confirmed by Sentry's own users, not just by reading the docs. In the GitHub discussion announcing the widget's beta, a commenter asked directly for "a classification for the feedback (reaction, feature request, issue)" similar to how Microsoft's in-product feedback tools split submissions into categories. A Sentry maintainer's reply confirmed there's no built-in equivalent, and pointed to the same workaround: "use your own widget to meet this need... and set a custom tag so you can reflect what classification selection was made." Nearly three years and one SDK rewrite later, that's still the shape of the answer, tags applied by you, not a field Sentry ships.
Building the classification Sentry doesn't ship
The tags option is real and it's the whole mechanism. Sentry's configuration docs let you pass a tags object to Sentry.feedbackIntegration(), which attaches to every submission from that widget instance:
Sentry.feedbackIntegration({
tags: { feedback_source: "in-app-widget", feedback_kind: "unclassified" },
});A static tag on the integration doesn't get you anywhere on its own, since every submission would carry the same value, and there's no way to make that value vary per submission from inside the widget. The configuration API exposes onFormOpen and onSubmitSuccess callbacks, but they fire before and after a submission, not during it, and the full options table has no dropdown, select, or custom-field mechanism anywhere in it. The only form fields the widget has are name, email, message, and screenshot, and the only things you can do to them are show, hide, require, or relabel.
Getting a per-submission value means the docs' own fallback: "if the available options are insufficient, you can use your own UI," calling Sentry.captureFeedback() directly with a form you built yourself, passing message (required) plus name and email (optional), and setting a tag on the scope before the call to carry whatever category you designed. That's not an alternative sitting next to the built-in widget, it's a replacement for it: the widget disappears, and your own three-option form takes its place.
Someone still has to look at the raw description text and decide bug versus feature versus praise before a tag can be attached, unless you've replaced the widget entirely. That's the point where a lot of teams' classification systems quietly stop working, because building a whole custom submission form just to get one dropdown is more effort than most teams will spend on an internal feedback widget, so the built-in form stays in place, untagged, indefinitely.
Noor's inbox at Anvil Health
Booking software for physical therapy clinics is Anvil Health's whole product, and Noor Bregman engineers the patient-facing side of it. The patient-facing scheduling portal has had the Sentry widget installed for about four months, mostly to catch JavaScript errors on the calendar picker that support couldn't reproduce from ticket descriptions alone.
By the third month, the feedback stream had drifted well past crash reports. A clinic front-desk manager typed "can we text patients their appointment time instead of only emailing" into the same widget that a broken date-picker error had triggered for someone else that morning. Both landed in the Sentry Feedback view with identical shape: description, no screenshot, no replay, an email address.
Noor put the problem in a Slack message to her team before proposing a fix: "Out of this week's 22 widget submissions, maybe six are actual bugs. I can't file the rest anywhere useful, there's nothing marking which is which, so I have to open each one and read it."
The fix wasn't a setting inside the Sentry widget, since there was nowhere in its configuration to add one. Noor replaced the widget with a small form of her own: three radio options (bug, feature request, question), submitting through Sentry.captureFeedback() with a feedback_kind tag set to whichever the clinic user picked, plus a saved Sentry search per value. It worked immediately for anything submitted after the change shipped. It did nothing for the four months of history already sitting in the inbox, and it depended on every clinic user actually picking the right option, which roughly a fifth of them didn't bother to do.
Where tagging by hand stops working
The tag-and-filter approach is genuinely sufficient at low volume, and it's the right first step; don't skip it. It stops scaling for reasons that are structural, not a tooling gap you can patch with one more label:
- The selector only classifies what people bother to fill in. Free-text submissions with no dropdown, or ones where a user picks "bug" for something that's actually a request, still need a human read to catch.
- Tags don't dedupe. Ten people describing the same missing feature in ten different phrasings still produce ten separate, individually-tagged submissions. Someone has to notice the pattern.
- Sentry only sees what came through the widget. The same request arriving in a support ticket, a sales call, or a Slack DM from an account manager doesn't join up with the widget submission automatically, so "how many customers want this" is a manual cross-reference across tools.
That third point is usually where teams stop trying to fix it inside Sentry. Once feedback needs to be read for intent, deduplicated against everything else customers are already saying elsewhere, and routed with the requester attached, that's a different job than a form field, however well-tagged.
That's the layer Modem works on. Modem's Sentry integration reads every widget submission the way Noor did by hand, classifies bug versus feature request versus reaction on the description itself rather than relying on a dropdown, and matches it against the same request arriving in Slack, a support ticket, or a call transcript. A feature ask no longer depends on the person filling out the widget correctly; it gets folded into a counted topic with every requester attached, the same context graph that tracks a request across every other channel it shows up in.
Modem is the company writing this, so read that paragraph knowing it's talking its own book. Other tools built for the same gap are compared in the best in-app feedback widgets. If Anvil Health's widget were still producing 22 submissions a month, Noor's custom form and three saved searches would keep working fine; what stopped working was the volume, not the tagging idea itself.
Start with the tag, not a rebuild
You don't need Noor's custom form to get a first win. Set a static tag in your existing feedbackIntegration() config, one value per environment or product surface the widget runs on, and save a Sentry search per tag so a bug-heavy surface stops competing with a feature-request-heavy one in the same view. That's a config change, not new code, and it's live in minutes. The custom-form step is worth the effort once one static tag isn't granular enough, and it's worth knowing going in that it means replacing the widget's UI outright, not adding an option to it.
