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.
New submission on your "Request a feature" form
Create a Jira issue of type Story in your roadmap project, with the idea as the summary, the full context in the description, and a "feature-request" label for filtering
One-directional. A submission triggers the action — nothing is written back into your form.
Feature requests arrive from everywhere: sales calls, customer emails, a colleague catching you in a corridor. Pointing all of them at one form gives every idea the same shape by the time it reaches the roadmap — a title, the problem behind it, and how badly the requester wants it.
Product managers use this when the backlog is the single source of truth and anything outside it effectively does not exist. The label keeps form-sourced ideas filterable, so they can be reviewed as one batch rather than found by accident.
Setting it up
- 1
Publish the feature request form, then check that Story is enabled as an issue type in the roadmap project — some Jira project templates hide it.
- 2
In Zapier, connect the formformform "New Submission" trigger to that form and run a sample so all eight answers show up as mapping options.
- 3
Add "Create Issue", select the roadmap project, and set Issue Type to Story.
- 4
Map the feature title straight to the summary. Requesters tend to write these as a short phrase, which is exactly what a backlog row needs.
- 5
Build the description in the order a reviewer reads it: the problem first, then what the requester wants, then how they work around it today.
- 6
Add a static "feature-request" label so a saved filter can pull these Stories out of a mixed backlog.
- 7
Map the importance answer to a custom field rather than Priority, unless you want requester opinion driving the same field engineering uses for delivery.
- 8
Submit a test request, confirm the Story arrives unranked at the bottom of the backlog where you expect it, then switch the Zap on.
What maps where
Using the Feature Request Form as the starting point. These are its real fields — swap in your own and the mapping works the same way.
| Form field | Jira |
|---|---|
| Feature Title | Jira issue summary |
| What problem does this solve? | Description, first section |
| What would you like to see? | Description, proposed solution section |
| How are you working around it today? | Description, current workaround section |
| How important is this to you? | Custom requester-demand field |
| Email Address | Custom requester contact field |
Variations worth knowing
Publish the same form twice and give each Zap a different label — "feature-request" and "internal-idea". Both land in the roadmap project, and a saved filter tells you which pressure a Story came from.
Add a question asking which area of the product the idea touches, then map that answer to the parent field in the Jira action. New Stories arrive already sitting under the initiative they belong to.
If something isn't arriving
Jira projects often make a field mandatory on creation — epic link, team, or a custom category. Open the create screen in Jira, note every required field, and give each one a value or default in the Zapier action.
Some requesters treat the title box as the whole pitch. Make the title field short with a character limit on the form, and rely on the problem and solution questions to carry the detail into the description.
Frequently asked questions
Should feature requests sit in the same project as engineering work?
That is a Jira question rather than a form one. Many teams keep a separate intake project and move a Story across once it is accepted, which stops raw requests inflating sprint reports. The Zap only needs a project key either way.
Can I stop obvious spam becoming a Story?
Add a Zapier filter that requires the problem answer to be longer than a few characters, and exclude disposable email domains. Filtered submissions stay in your formformform responses, so you can check what was caught.
Will the requester find out their idea was accepted?
Not automatically — nothing flows back from Jira to the form. The form captures an email address, so most teams export the addresses behind a shipped Story and send one round of updates when the work goes live.
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.
- 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.
- 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