Send bug reports to your engineering backlog
Each report arrives in the Engineering backlog as a bug-labelled issue with reproduction steps already written.
New submission on your "Report a bug" form
Create an issue in your Engineering team with the report as the description, a "bug" label, priority mapped from the form, and a Backlog state
One-directional. A submission triggers the action — nothing is written back into your form.
Bugs arrive by email, by chat message, and by someone stopping an engineer in the corridor. None of those become an issue anyone can plan around. A short public form gives customers and colleagues one place to report, and this flow files what they wrote directly into the backlog.
It suits SaaS teams whose engineers own triage. The issue opens already carrying the reproduction steps and the severity the reporter picked, so the first decision is whether to fix it, not whether the report is usable at all.
Setting it up
- 1
Publish your "Report a bug" form and file one real report through it, so Zapier has a sample where the severity and the reproduction fields are all populated.
- 2
In Zapier, choose formformform's New Submission trigger and select the bug form, then run the test until the report you just filed comes back.
- 3
Add Linear's Create Issue action and pick your Engineering team as the destination.
- 4
Map Bug Title to the Linear issue title. If the same board carries product work, prefix it so defects stand out in the list.
- 5
Build the description from Steps to Reproduce, What Actually Happened? and What Did You Expect to Happen?, each under its own heading, then append the URL and browser underneath.
- 6
Set the Labels field to bug. Create that label in Linear first — Zapier can only apply labels that already exist on the team.
- 7
Translate Severity into Linear's priority scale with a Formatter lookup step: highest option to Urgent, middle to High or Medium, lowest to Low.
- 8
Set the state to Backlog rather than Todo, send a second test report, confirm the issue reads well enough to work from, then switch the Zap on.
What maps where
Using the Bug Report Form as the starting point. These are its real fields — swap in your own and the mapping works the same way.
| Form field | Linear |
|---|---|
| Bug Title | Issue title |
| Severity | Issue priority, Urgent through Low |
| Steps to Reproduce | Issue description, under a Steps heading |
| What Actually Happened? | Issue description, under an Observed heading |
| Browser / Device | Issue description, environment line |
| URL Where the Bug Occurs | Issue description, link at the bottom |
Variations worth knowing
Add a Zapier filter after the trigger so only reports at the top severity create an issue in Engineering. Send the rest through a second Zap into a lower-traffic team. Engineers then stop seeing cosmetic problems in the same list as an outage.
Use conditional logic so the browser and URL questions appear only for web reports, then filter in Zapier on Steps to Reproduce being answered. Half-written reports stay in your response list instead of cluttering the Engineering board, and you can still read them.
If something isn't arriving
Linear will not create a label from a Zap. Open your Engineering team's label settings, add bug there, then reopen the Zapier action step and refresh the label dropdown so the new option appears before you select it.
Linear's priority is a fixed scale, not free text, so passing the severity answer straight through leaves it unset. Add a Zapier Formatter lookup that turns each severity option into Urgent, High, Medium or Low before the Linear step runs.
Frequently asked questions
What makes a bug report worth an issue?
Anything with steps another person can follow. Make Steps to Reproduce a required field and most of the unusable reports stop arriving. Reports that still lack detail can be cancelled in Linear, and the original submission stays in your responses if the reporter follows up.
Does the reporter get told when the bug is fixed?
No. The connection runs one way: a submission creates an issue, and nothing Linear does is written back to the form or to the person who filed it. Their email address is on the issue, so whoever closes it can reply directly.
Can I keep the reporter's email out of Linear?
Yes. Leave Email Address out of the mapping and it never reaches the issue. It stays in your formformform responses, where you can search for it when a specific report needs a follow-up, without the whole workspace seeing it.
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.
- 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.
- 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