Log bug reports as prioritised Problem tickets
Each problem report becomes a Problem ticket in Zendesk, tagged and already carrying the priority the reporter chose.
New submission on your "Report a problem" form
Create a Zendesk ticket of type Problem with steps to reproduce in the description, Priority mapped from an urgency dropdown, and a "bug" tag added
One-directional. A submission triggers the action — nothing is written back into your form.
A bug report is only useful if it can be reproduced. Free-text email rarely gets there — the browser is missing, the steps are a summary, and the first reply is always a request for more. A structured form collects the same details from everyone and files them as a Problem ticket.
This one suits product teams whose customers report faults directly. Priority comes from the reporter's own severity choice, so an urgent regression is visible in the triage view before anyone has read a word of it.
Setting it up
- 1
Publish the "Report a problem" form with Severity offering exactly Low, Normal, High and Urgent — Zendesk's own four priority values — so nothing has to be translated in between.
- 2
In Zapier, choose formformform's "New Submission" trigger and select the bug report form rather than your general contact form.
- 3
Add the Zendesk "Create Ticket" action, connect your subdomain, and fix Type to Problem so later duplicates can be linked to it as Incidents.
- 4
Point Zendesk Priority at the Severity field. Where the two vocabularies disagree, a Formatter lookup table between the two steps is safer than rewording a form that people outside the team read.
- 5
Compose the description from Steps to Reproduce first, then What Did You Expect to Happen? and What Actually Happened? — reproduction before opinion is the order an engineer reads in.
- 6
Put Bug Title on the subject line, and append Browser / Device and URL Where the Bug Occurs at the foot of the description so the environment travels with the report.
- 7
Add "bug" as a static tag, then create a Zendesk view filtered on that tag and sorted by priority. That view is where triage happens.
- 8
Fire one test report at Urgent and one at Low, confirm both land with the right priority and tag, then enable the Zap.
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 | Zendesk |
|---|---|
| Bug Title | Ticket subject |
| Severity | Ticket priority (Low, Normal, High, Urgent) |
| Steps to Reproduce | Opening lines of the ticket description |
| What Actually Happened? | Description, below the reproduction steps |
| Browser / Device | Custom ticket field recording the environment |
| Email Address | Requester email, so the reporter can be updated |
Variations worth knowing
When several people report the same fault, keep the first ticket as the Problem and switch the later ones to Incident linked against it. Solving the Problem closes the linked Incidents and notifies every reporter at once, which is why Type is worth fixing on the action step.
Add a Zapier path so Urgent reports also post to your on-call channel, or let a Zendesk trigger notify the group on that priority alone. Everything below Urgent stays in the tagged view and waits for the weekly triage pass.
If something isn't arriving
Zendesk accepts only low, normal, high and urgent as priority values and falls back silently when it gets anything else. Check the exact strings your dropdown sends — casing is forgiven, "Critical" or "P1" is not — and add a lookup table where they differ.
Ticket type is controlled by the ticket form in Zendesk. If your default ticket form hides Problem, add it in Admin Center, then reconnect the Zendesk step in Zapier so the refreshed field options load.
Frequently asked questions
Can engineers work the bug in Zendesk without a support licence?
Zendesk seats are per agent, so an engineer without one cannot pick the ticket up. Most teams triage in Zendesk and push accepted reports into Jira or Linear as a second Zapier action, leaving the ticket as the customer-facing record of the report.
Does the reporter find out when the bug is fixed?
Not from the form. Solving the Zendesk ticket emails the requester when you mapped their address, and solving the parent Problem notifies every linked Incident at once. The submission itself is never written back to — it stays as first sent.
Should severity be chosen by the customer or by us?
Let them choose, then review it. A customer's Urgent is about their day rather than your queue, so the mapped priority is an opening position. Agents raise or lower it in Zendesk after triage, and the form is none the wiser.
Related automations
- Capture webinar questions as tagged tickets
Questions from webinar registrations open as tickets tagged with the event, ready for the host to answer from one view.
- Collect post-support feedback as low-priority review tickets
Post-support feedback lands as a low-priority tagged ticket in a review view, out of the queue agents work each day.
- Open internal IT requests as prioritised tickets
Staff IT requests become prioritised tickets on your internal Zendesk queue, with the device and issue type already on them.
- Route order and refund requests to the Billing group
Order and refund questions open in the Billing group with the order number already on the subject line.
- Send contact form messages to your support queue
Messages from your contact form open as Zendesk tickets, with a status, a group and the sender already resolved as the requester.
- 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