Turn support requests into Jira tasks
Contact-support submissions arrive as labelled Task issues in your support project, message intact and ready to assign.
New submission on your "Contact support" form
Create a Jira issue of type Task in your support project, with the customer's message in the description, a "support" label, and the reporter's email recorded on the issue
One-directional. A submission triggers the action — nothing is written back into your form.
Support queues run badly when half the requests live in a shared mailbox and the other half live on the board. This flow removes the mailbox half. What the customer typed reaches Jira unedited, so the first person to pick the issue up reads the original words.
Small teams reach for it first — a handful of agents who already stand at a Jira board every morning and would rather not switch tools to find out what came in overnight.
Setting it up
- 1
Publish your contact-support form and decide which project the queue lives in. Most teams use one support project with a single board rather than splitting by topic.
- 2
In Zapier, point the formformform "New Submission" trigger at that form and load a sample submission so the subject and message answers appear in the mapping list.
- 3
Add Jira's "Create Issue" action, choose the support project, and set Issue Type to Task so the requests sit alongside the rest of the team's work.
- 4
Map the subject answer to the summary. If subject is optional on your form, add a Zapier fallback value so an empty one never creates a nameless issue.
- 5
Put the message into the description, with the customer's name and email on lines above it so whoever picks the issue up can reply without leaving Jira.
- 6
Type "support" into the Labels field as a static value rather than mapping it from an answer — Jira labels have to be a single word.
- 7
Set the assignee, either to a triage owner or to nobody if the team pulls work from an unassigned column.
- 8
Run a submission through the live form, confirm the issue lands in the right column carrying the label, then turn the Zap on.
What maps where
Using the Contact Form as the starting point. These are its real fields — swap in your own and the mapping works the same way.
| Form field | Jira |
|---|---|
| Subject | Jira issue summary |
| Message | Issue description |
| Email Address | Custom customer email field, plus the description header |
| Full Name | Custom customer name field |
| Phone Number | Description, for requests that need a call back |
Variations worth knowing
Add a dropdown asking what the request is about, then use Zapier paths to send billing questions to one project and technical problems to another. Each path keeps its own Jira action, so the issue types can differ too.
Filter on the email domain and give matching submissions a second label such as "priority-account" before the Jira step. Everything else follows the standard path, so nothing is excluded, only marked.
If something isn't arriving
Jira labels cannot contain spaces. A label mapped from a free-text answer like "billing question" is rejected or split in two. Use a static single-word label in the Zap and keep the free text in the description.
The subject field is free text and some customers paste a paragraph into it. Add a Zapier Formatter step that truncates to roughly eighty characters before the Jira action, and keep the full text in the description.
Frequently asked questions
Does commenting on the Jira issue reply to the customer?
No. Jira comments stay in Jira. The link between form and board is one-directional, so replies still go out through your mail tool. Keeping the customer's address on the issue at least puts it one click away.
Can the issue be assigned automatically?
Yes, in the Jira action. Set one person for the whole queue, or drive it from a form answer using Zapier paths. Jira Cloud matches on account ID rather than display name, so pick the user from the dropdown instead of typing a name.
Do we have to send every request to Jira?
No. A Zapier filter between the trigger and the action decides which submissions continue. Everything else is still stored as a response in formformform, searchable and exportable — it simply never becomes an issue.
Related automations
- Create a Jira Bug issue from every bug report
Every submission on your bug report form opens a Bug issue in the product project, with severity already mapped to Jira Priority.
- Create an assigned Jira task for every new hire's IT setup
A completed onboarding form creates an assigned setup Task in the IT project, with equipment and access needs listed in the description.
- File feature requests as Jira stories in your roadmap
Each feature request lands as a Story in your roadmap project, labelled so you can review the form-sourced ideas as a batch.
- Send beta feedback to Jira as triageable issues
Beta survey responses become labelled Task issues in the QA project, each tagged to the component the tester was using.
- Turn internal IT requests into prioritised Jira issues
Internal IT requests become prioritised issues on the team board, with the change type as the summary and a requested completion date.
- 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