Route bug reports into a tagged engineering conversation
Bug reports open in the Engineering mailbox, tagged and carrying the severity and reproduction steps the reporter filled in.
New Submission on your "Report a bug" form
Create a conversation in the Engineering mailbox with the severity and steps-to-reproduce fields in the body, tagged "bug"
One-directional. A submission triggers the action — nothing is written back into your form.
A bug report that arrives as an email in a support inbox gets forwarded, then forwarded again, and the detail falls off along the way. Sending the report straight into an Engineering mailbox keeps the severity, the steps and the browser together in one conversation.
Product support teams use this to stop being the relay. Engineers watch one queue, the reporter stays attached to the thread, and the person who filed it can be told when the fix ships.
Setting it up
- 1
Publish "Report a bug" with Severity as a choice field rather than free text. A Help Scout workflow can only match values it recognises, and typed severities never match.
- 2
Use conditional logic so URL Where the Bug Occurs only appears for browser issues, which keeps the body short on reports that are not web related.
- 3
In Zapier, set the trigger to formformform's "New Submission" and select the bug form.
- 4
Choose Help Scout's "Create Conversation" action and set Mailbox to Engineering, not Support. Engineers should watch one queue rather than filter someone else's.
- 5
Map Bug Title to the conversation subject. If reporters write vaguely, prefix it in Zapier with a static "[Bug]" so the mailbox list reads at a glance.
- 6
Build the thread body from Severity, Steps to Reproduce, What Actually Happened? and Browser / Device in that order, with a short heading before each so the paragraphs do not run together.
- 7
Add the static tag bug on the action, then let a Help Scout workflow add a second tag from the severity value so the mailbox can be filtered by how bad it is.
- 8
Map Email Address to the customer so the reporter is on the thread, test with a real report, then turn 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 | Help Scout |
|---|---|
| Bug Title | Conversation subject in the Engineering mailbox |
| Severity | First line of the body, and the value a workflow reads to add a severity tag |
| Steps to Reproduce | Numbered steps in the conversation body |
| What Actually Happened? | Body, under an actual-result heading |
| Browser / Device | Body, next to the URL so an engineer can reproduce it |
| Email Address | Customer on the conversation, so the reporter can be answered |
Variations worth knowing
The bug form has a Screenshot or Video Link field. Ask reporters to paste a URL from whatever recorder they already use, map it into the body, and Help Scout renders it as a clickable line an engineer can open while reading the steps.
Add a Zapier filter after the trigger so reports at the top of the severity list also post to your on-call channel, while everything else simply opens in Engineering. The conversation is created either way; the filter only gates the extra step.
If something isn't arriving
A mailbox with no assignment rule leaves everything unassigned, and Help Scout notifies followers and assignees rather than everyone with access. Add a workflow on the bug tag that assigns to the on-call engineer, or have the team follow the Engineering mailbox.
Zapier sends plain text unless the thread body is set to HTML. Switch the body to HTML, separate each mapped field with a line break or a short heading, and re-test. Help Scout renders the markup in the conversation.
Frequently asked questions
Should bug reports go to a mailbox or straight to our issue tracker?
A mailbox keeps the reporter attached, so the person who filed it can be answered. Many teams do both: the conversation for the human, a second Zapier action for the tracker. A closed issue with no reply still reads as silence to whoever reported it.
Can engineers reply to the reporter from the Engineering mailbox?
Yes, provided that mailbox has a sending address configured. The reply goes out by email from it and the thread stays in Help Scout. Nothing is written back into the submission, which keeps the original report intact as filed.
What do I do when the same bug arrives from several customers?
Help Scout can merge conversations. Filter on the bug tag, open the duplicates and merge them into the first one. Every customer stays attached to the merged thread, so a single reply reaches all of them once the fix ships.
Related automations
- Collect product feedback as tagged conversations
Ratings and comments open as tagged conversations in a Feedback mailbox you can filter, search and revisit when planning.
- Create the customer record before the first reply
Onboarding intake answers become a Help Scout customer record, so agents see who the person is before the first conversation opens.
- Land demo requests in the sales mailbox
Demo requests open as conversations in the Sales mailbox, carrying company size, the problem to solve and the timing.
- Open a support conversation from every contact form message
Each contact form message arrives in your Support mailbox as a conversation, attributed to the sender and ready to assign.
- Send refund requests to the billing mailbox
Refund requests become trackable conversations in the Billing mailbox, with the order number in the subject and an owner attached.
- Capture feature requests as labelled tickets
Product ideas from your feedback form land in Freshdesk as Feature Request tickets the team can group and revisit.
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