Route customer feedback into a triage view
Feedback arrives in Triage as a labelled issue the team can accept, decline, or move into a project.
New submission on your feedback survey
Create an issue in your Triage team with the comment as the description and a category label taken from the form's feedback type dropdown
One-directional. A submission triggers the action — nothing is written back into your form.
Qualitative feedback is easy to collect and hard to act on. A comment box fills up with praise, confusion and one genuinely useful observation, and no one has a habit for reading it. Linear Triage gives that stream somewhere to sit where ignoring it becomes a visible decision.
Small product teams use this when there is no research function to hand the comments to. Every response becomes an issue with its category label already applied, so the weekly triage pass is filtering and deciding rather than copying text between tools.
Setting it up
- 1
Add labels to your Linear Triage team that match your form's feedback type options, spelled exactly the same way in both places.
- 2
Publish the feedback form and embed it on the pages you want comments about, then send one test comment through the live embed.
- 3
In Zapier, choose formformform's New Submission trigger and select the feedback form.
- 4
Add Linear's Create Issue action and set the team to Triage, not to a product team's backlog.
- 5
Map Describe the Issue or Suggestion into the issue description, and build the title from the feedback type plus the page it came from.
- 6
Add a Formatter lookup that converts each feedback type option into the matching Linear label, then map its output to the Labels field.
- 7
Put the page URL, the browser and the blocker answer at the bottom of the description, so a comment about a broken layout is actionable without an email exchange.
- 8
Test, confirm the issue appears in the Triage view rather than a backlog, then turn the Zap on.
What maps where
Using the Website Feedback Form as the starting point. These are its real fields — swap in your own and the mapping works the same way.
| Form field | Linear |
|---|---|
| Type of Feedback | Label on the Linear issue |
| Describe the Issue or Suggestion | Issue description |
| Page URL Where You Noticed the Issue | Issue description, link at the bottom |
| Browser and Device | Issue description, environment line |
| Is this issue preventing you from completing a task? | Issue description, used to sort during triage |
| How often do you visit this site? | Issue description, how much weight the comment carries |
Variations worth knowing
Build a second Zap filtered on the blocker question. When someone says the problem stopped them completing a task, create the issue in Engineering at High priority instead, so a broken checkout is not sitting in a queue waiting for Thursday's review.
Not every comment deserves an issue. Filter on the feedback type so compliments never reach the tracker. They stay searchable in your formformform responses, ready to be pulled out when someone is writing a testimonial page, while problems carry on into Triage.
If something isn't arriving
Linear matches labels by exact name and the Zap still reports success when nothing matches. If your form says "Bug report" and the label is "bug", rename one side, or add a Formatter lookup that translates each dropdown option.
The email question on this form is optional, so many rows come through empty. Make it required if follow-up matters to you, or accept that some feedback is a data point rather than a conversation and stop chasing the anonymous ones.
Frequently asked questions
How is Linear Triage different from a normal backlog?
Triage is a holding area that belongs to a team. Issues wait there until someone accepts, declines, or moves them into a project, which means feedback never lands in an active cycle by accident and declining something is recorded rather than silent.
Should every comment become an issue?
No, and filtering in Zapier before the Linear step matters more than it sounds. If Triage fills with one-line thanks, the team learns to skim past it. Send through anything describing a problem or asking for something, and leave the rest.
Can I collect feedback from one page only?
Embed the form on that page as an inline block or a slide-in and it only collects from there. The page URL question still earns its place when the same embed appears in several places, or when someone reaches the form by shared link.
Related automations
- Create design tasks from a campaign brief
Each brief becomes a Design team issue in the right project, with the campaign context already in the description.
- File feature requests into a product project
Requests land in your Product team's project as labelled low-priority issues, grouped and ready to weigh at planning.
- Send bug reports to your engineering backlog
Each report arrives in the Engineering backlog as a bug-labelled issue with reproduction steps already written.
- Send internal IT requests to your operations team
Hardware, access and tooling requests become assigned Operations issues with a priority, so the queue stays visible.
- Turn support escalations into tracked issues
Complaints that need an engineering fix become prioritised, customer-labelled issues in your Support team.
- Add every RSVP to your confirmed guest list
Each RSVP creates a card on the "Confirmed guests" list with the ticket type as a label and dietary notes in the description.
Build the form first
The automation needs somewhere to fire from. Publish a form, connect it once, and every submission from then on runs this flow.
Start free