November 2026: feedback form questions, screenshots and Kanban

Our February update introduced quick actions on feedback cards. This update covers the changes we've made since then.

We've changed the feedback forms and added more ways to review submissions. You can ask different questions for bugs and feature requests, attach a marked-up screenshot, and move feedback through a Kanban board. There are also smaller additions that help with setting up a portal, reviewing duplicates and keeping track of replies.

Choose questions for each feedback category

A bug report and a feature request need different follow-up questions. "What happened?" is useful for a bug, but it doesn't tell you much about why someone needs a new feature.

You can now choose which questions appear for each feedback category. The starting questions cover:

• Bugs: the steps that caused the problem, what the person expected, and what actually happened.
• Feature requests: what the person is trying to achieve and how they handle it today.

You can edit those questions, add your own, show a question in every category, and decide which answers are required. Each portal can have up to 12 questions. Example placeholders give people a starting point when they're unsure what to write.

These settings apply to the embedded widget, public portal and feedback form in the main app. Set them up once under Portal Settings → Feedback collection.

Screenshots you can mark up before sending

Sometimes it's easier to point at a problem than describe it. People submitting feedback can now attach a screenshot and draw on it, put a box around something, or add an arrow.

They can undo a mark, replace the image or remove it before submitting. The finished screenshot stays with the feedback, alongside the answers to your questions.

This works in the widget, public portal and main app. Screenshot collection is optional, and you can switch it off for your portal.

Page and browser details, with a choice about sharing them

"Which page were you on?" is often the first question after a bug report. Feedback forms can now include the page address, browser, language and window size with the submission.

The person sending the feedback can review those details and untick the option if they don't want to include them. URL query parameters and fragments are left out. You can also turn this collection off in your portal's feedback settings.

For an embedded widget, that means the report can include the page in your own product where the person was having trouble.

A Kanban board for your feedback

The feedback list now has a Kanban view. Items sit in columns for New, Under Review, Planned, In Progress and Completed, so you can see how work is moving without opening each item.

Team members with permission to change statuses can drag cards between columns. Moving an item to Planned gives you the option to add it to the roadmap. Marking it Completed gives you the option to include it in a changelog.

You can switch between the list and board, and there's a Kanban shortcut on the portal dashboard.

Dismiss duplicate suggestions that aren't duplicates

Two requests can sound similar and still be asking for different things. In the duplicate review screen, you can now dismiss a suggested group when the items should stay separate.

The feedback remains in place. Dismissing the suggestion keeps that group out of the duplicate queue, so you don't have to keep reviewing the same decision.

We've also corrected mismatches between duplicate counts and the items shown, including the submission warning that could claim similar feedback existed while displaying no matches.

Keep comments that don't need a reply out of your queue

Not every comment needs an answer. A thank-you, an acknowledgement or a conversation that's already finished can otherwise sit in the unanswered list indefinitely.

You can now mark a comment as ignored for reply checks. It stays on the feedback item, but stops contributing to the unanswered queue. If it needs attention later, you can unignore it.

Use the original date of a request

When you're adding feedback from an email, a call or an older record, today's date isn't always the right date.

You can now choose the request date when creating a feedback item and change it when editing one. That lets you record when the request was first made, rather than when someone had time to enter it into FeedbackNexus.

A portal launch checklist

The portal dashboard now includes a launch checklist. It shows what's ready and what still needs a look before you invite customers.

The checklist covers accepting feedback, reviewing branding, setting up categories and tags, preparing the widget, connecting team notifications and collecting your first feedback item. Each step takes you to the relevant screen, and features that depend on your plan are marked accordingly.

Once you're happy with the setup, you can mark the checklist complete and hide it.

Dark mode for the embedded widget

The widget now supports light and dark themes, including following the system preference. The feedback form, comments and other widget screens use the selected theme too.

If your product has a dark interface, the feedback widget can fit in with the rest of the page.

More choice when adding completed work to a changelog

Completed work doesn't always need a separate release announcement. When adding completed items to your changelog, you can now choose to:

• Create a new release.
• Add them to your most recent draft.
• Add them to your most recent published release.

This is useful when you're gathering several changes into one update, or when you notice something missing from an announcement you've already published.

Response reports now count public team replies

Response rates and average response times now use the first public reply from your team. A status change, internal note or customer comment doesn't count as your team answering the request.

We've corrected those calculations in the feedback insights and executive summary reports, including exports. We've also fixed the links from insight cards so you can open the feedback behind a result and read it in context.

Completed items are now excluded from stale-feedback counts, too, so finished work doesn't look like something you've left waiting.

Other fixes and additions

• Retry failed webhook notifications. Where a saved payload is available, you can retry a failed notification from the webhook logs. The retry result is recorded there too.
• A backup for writing suggestions. The AI writing tools use updated models and can try a second service if the first one is unavailable.
• Fewer false restrictions. We've adjusted spam and rate-limit checks that could interrupt ordinary use, including legitimate feedback being blocked because of a word in its description.
• More reliable updates. We've fixed caching problems that could leave a tab running an older app after a refresh. The version shown in the footer now reflects the release number rather than the deployment counter.
• Smaller interface fixes. These include comment buttons, copying portal settings, chip sizing and colours, and display problems when using the web app from an iPhone home screen.

Try the new collection options

If you're already using FeedbackNexus, open Portal Settings → Feedback collection and review the questions your customers see. Then try submitting a bug report through your portal or widget to see the form from their side.

We'd like to hear how these changes work for you. If something is missing, or a question comes up while you're setting things up, get in touch.