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.
New submission on your beta feedback survey
Create a Jira issue of type Task in your QA project, with the feedback in the description, a "beta" label, and the component set from a form field
One-directional. A submission triggers the action — nothing is written back into your form.
During a beta the feedback is the deliverable, and it arrives faster than anyone can sort it. Sending each response to the QA board tagged by component means a week of testing can be read component by component rather than top to bottom.
QA leads set this up before the beta opens rather than during it. The board becomes the record of what testers said, while the survey keeps the ratings in formformform for the numbers at the end of the round.
Setting it up
- 1
List the components already defined in your QA project, then word the product question on the survey so its answers match those component names.
- 2
Publish the beta feedback survey and send it to testers with the round clearly named, so responses can be grouped afterwards.
- 3
In Zapier, point the formformform "New Submission" trigger at the survey and load a sample response.
- 4
Add "Create Issue", choose the QA project, and set Issue Type to Task.
- 5
Map the product answer to the Components field. Jira matches components by exact name and quietly ignores anything it cannot find.
- 6
Put the written feedback into the description, with the reliability rating on a line above it so triage can sort by severity at a glance.
- 7
Add a static "beta" label, including the round number if you plan to run more than one round of testing.
- 8
Submit a test response the way a tester would, confirm the component and label are both set, then enable the Zap.
What maps where
Using the Product Feedback Survey as the starting point. These are its real fields — swap in your own and the mapping works the same way.
| Form field | Jira |
|---|---|
| Product Name or Model | Components field on the issue |
| What features are missing or need improvement? | Issue description, main body |
| Build quality or software reliability | Description, rating line above the feedback |
| What features or aspects do you like most? | Description, context section |
| Email Address | Custom tester contact field, or left unmapped |
Variations worth knowing
Add a Zapier filter on the reliability rating so only poor scores create issues. Positive responses stay in formformform as data you export at the end of the round, which keeps the QA board about defects.
Keep the same project and change the label to "beta-2" when the next round opens. Old feedback stays readable as a group, and a saved filter per round shows whether the same components keep coming back.
If something isn't arriving
Components must already exist in the project and match by name exactly. If testers type freely, add a Formatter lookup that translates each answer into an existing component and leaves the field empty when there is no match.
The survey's written questions are optional, so a tester who only moves the rating sliders produces a blank body. Make at least one written question required, or map the ratings into the description as a fallback.
Frequently asked questions
Do beta testers need a Jira licence?
No. Testers never touch Jira. They fill in the survey, and the Zap creates each issue under the account you connected in Zapier, so only the QA team needs seats on the board.
Can we keep the tester anonymous on the issue?
Yes. Leave the name and email answers out of the mapping and they never reach Jira, even though they are still stored with the response in formformform. Reviewers read the feedback without knowing who wrote it.
How do we tell beta issues apart from ordinary QA work?
The static label does it — a saved filter on "beta" returns only the form-sourced issues. Putting the round number in the label keeps successive rounds separate without needing a second Jira project.
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.
- 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.
- Turn support requests into Jira tasks
Contact-support submissions arrive as labelled Task issues in your support project, message intact and ready to assign.
- 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