Userback

Userback is a visual website feedback and bug reporting tool. Agents list and update feedback, add comments and screenshots, move items through workflows, and review projects, members, and session recordings.

Verified 21 actions API key available

Userback website Platform Documentation Capability data verified 2026-08-25

A visual bug report is submitted through the Userback widget on a project

Get Feedback returns the item with its screenshots, reporter, and project

List Session Recordings finds the recording that shows what the user did beforehand

List Feedback Comments is filtered to this item's thread to see what has already been said

Update Feedback moves the item into the triage status and sets its priority and assignee

An engineering ticket is opened with the screenshot and the recording attached

A person decides what goes back to the reporter and what stays an internal note

What This Integration Enables

The thing to understand about Userback is that a feedback item is not a ticket. It is a thread, and the person who filed it is still on it. That single fact governs how this connector should be used, because almost every write here has an audience outside the company. Notifications default to on, so a routine status change emails the reporter. Comments carry a visibility flag that decides whether the customer sees them. An item can be published to a public portal. None of that is a flaw; it is what a feedback tool is for. It is simply not how a bug tracker behaves, and an agent that treats it like one will publish things.

Used well, that is exactly the strength. FlowRunner agents pull reports with their screenshots and session recordings, add the evidence a widget could not capture with Upload Feedback Screenshot, move items through the project's own status list, thread replies as comments, and mirror the whole thing into whatever the engineering team actually works in. Feedback that arrived from an email, a support ticket, or a form gets created here too, so the widget's reports and everything else finally live in one queue. The routing, the enrichment, and the mirroring run unattended. The moment something becomes visible to the customer is where FlowRunner's human-in-the-loop step belongs.

Without FlowRunner

Reports arrive without evidence A message saying a page is broken, with no URL, no browser, and no sense of what happened just before

Triage means retyping The report is copied into the engineering tracker by hand, and the two records drift apart from that moment on

The reporter never hears back The person who took the time to file it does not learn whether it was read, fixed, or dismissed

With FlowRunner

Context travels with the report Screenshot, session recording, project, and reporter arrive together in the ticket that gets worked

Status is a single write Moving an item through its Userback status updates the record the reporter can actually see

Replies are deliberate What reaches the reporter and what stays internal is decided, rather than inherited from a default

Use Case Scenarios

A report becomes a worked ticket without losing its evidence

A widget submission lands. The agent calls Get Feedback for the full item, then List Session Recordings and Get Session Recording to find the playback that shows what the user was doing beforehand, which is the piece a bug report is usually missing. It opens an issue in Linear with the screenshot, the recording link, and the reporter's own words, and posts a short summary to the engineering channel in Slack. Back in Userback, Update Feedback moves the item into the triage status and sets the assignee, reading List Members first so the assignee holds a role that can actually see the item. Nothing was retyped and nothing was summarized away.
Feedback from everywhere else joins the same queue

Not every complaint arrives through the widget. A reply to a support conversation in Intercom, a ticket in Zendesk, and a submission from a Typeform survey all describe product problems. The agent calls Create Feedback against the right project for each one, attaches any image with Upload Feedback Screenshot, and sets the status through the project's Userback statuses. For a historical import it turns notifications off deliberately, because the default would announce every old item to its original reporter as though it had just arrived. One backlog, one triage process, and no customer wondering why they got forty emails on a Tuesday.
The fix ships and the person who reported it finds out

An issue closes in GitHub. The agent finds the linked Userback item, drafts a reply that says what changed and where, and prepares Create Feedback Comment with the public visibility flag set so the reporter sees it. Before it posts, the draft goes to the account owner. Meanwhile the internal discussion on the same item stays as private comments, and the agent never edits an existing internal note's visibility, because turning that flag on publishes a note retroactively to everyone who can see the item. The status moves to resolved, the reporter gets one clear message, and the engineering conversation stays where it was written.

Human-in-Loop Highlight

Marking a feedback item as portal approved does two things at once. It publishes the item to the public portal, and it changes the item's type to an idea, which quietly moves it out of the bug queue it was filed into. So a routine triage rule that promotes popular reports can take a customer's description of a broken checkout, including whatever frustration they wrote at the time, and put it on a page anyone can read, filed as a suggestion. The comment side has the same shape: turning an existing internal comment public republishes it retroactively, and an engineering note about a customer cannot be unsent once their eyes are on it. So the agent does everything up to that line. It assembles the item, the reporter, the thread, and the vote count, and posts: "This report has 23 upvotes and is proposed for the public portal. Publishing it makes the reporter's original text public and reclassifies it from a bug to an idea. The thread also holds 4 internal comments, which stay private. Publish, publish with edited text, or keep it internal?" A person answers. Everything that happens before that moment is work no human should be doing, and the moment itself is not one an agent should own.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

21 actions

Feedback

List Feedback Returns the workspace's feedback items. The rows sit inside an envelope alongside the paging counts, which the connector returns whole so a flow can walk a long backlog.
Get Feedback Returns one item with its screenshots, project, and reporter. Field names here differ from the ones Userback's own webhook payload uses, so a flow that reads both translates rather than assuming.
Create Feedback Records a feedback item against a project. This is how feedback captured somewhere else, in an email, a support ticket, or a form, comes to live alongside what the widget collected. Notifications are on by default, which matters most on an import.
Update Feedback Changes an item: its status through the project's list, its priority, its assignee, or its text. Notifications default on here too, so a bulk status change reaches every reporter unless that is turned off deliberately.
Delete Feedback Removes an item. Its comments and screenshots go with it, and there is no archive to recover it from through this connector.
Upload Feedback Screenshot Attaches an image to an item. The way a flow adds evidence a widget never saw: a screenshot from a support ticket, a rendering of the failing page, or a frame pulled from a recording.

Comments

List Feedback Comments Returns comments. The route is the workspace's comment list rather than one item's thread, so it is filtered down to reach a single conversation.
Get Feedback Comment Returns one comment.
Create Feedback Comment Adds a comment to an item, optionally as a reply. Its visibility flag decides whether the reporter sees it or whether it stays an internal note, and that flag is set explicitly rather than left to a default.
Update Feedback Comment Edits a comment's text, author, or visibility. Turning visibility on publishes an existing internal note retroactively to everyone who can see the item, which is why this operation is never run unattended.
Delete Feedback Comment Removes a comment. Its replies go with it.

Projects and Members

List Projects Returns the workspace's projects, which is where each widget's feedback lands.
Get Project Returns one project.
List Members Returns the workspace's members with their roles. The role is what decides whether an assignee can see the item at all, so it is read before an assignment rather than after.
Get Member Returns one member.

Statuses

List Workflows Returns the statuses a feedback item can move between. In Userback the status is the workflow, so this is the list an update's status parameter is chosen from.
Create Workflow Adds a status an item can be in, within one project. Its color must be a hex value rather than a color name.
Update Workflow Renames a status or changes its color. Renaming moves no feedback: items already in it keep their place and follow the new name.
Delete Workflow Removes a status. Feedback currently sitting in it has to go somewhere, so what happens to those items is settled before the status is deleted.

Session Recordings

List Session Recordings Returns the workspace's session recordings. A recording shows what the user actually did before submitting, which is the part a written bug report almost never contains.
Get Session Recording Returns one recording with its playback details, ready to attach to the ticket the engineer will actually open.

Frequently Asked Questions

What can FlowRunner do with Userback?

FlowRunner agents can run List Feedback, Get Feedback, and Create Feedback in Userback, plus 18 more actions.

Does connecting Userback to FlowRunner require OAuth?

No. Userback connects to FlowRunner with an API key, no OAuth flow required.

Can Userback trigger a FlowRunner workflow automatically?

Userback doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Userback

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us