File feature requests into a product project
Requests land in your Product team's project as labelled low-priority issues, grouped and ready to weigh at planning.
New submission on your "Request a feature" form
Create an issue in your Product team, assign it to the relevant project, add a "feature-request" label, and set priority to Low
One-directional. A submission triggers the action — nothing is written back into your form.
Ideas turn up from users, from sales calls, and from the team's own chat threads. Left in those places they get repeated, argued over, and lost. A request form gives everyone one route in, and this flow parks each idea inside the Linear project it belongs to.
Product managers reach for it when planning is quarterly rather than continuous. Requests accumulate at Low priority all quarter, so nothing jumps the queue on arrival, and the whole set is sitting there to read when the roadmap gets rewritten.
Setting it up
- 1
Create the Linear project that will hold incoming ideas — a project called Requests is enough to start — and add a feature-request label to the Product team.
- 2
Publish your "Request a feature" form and submit one request yourself so Zapier has a sample with every answer filled in.
- 3
In Zapier, set the trigger to formformform's New Submission and pick the feature request form.
- 4
Add Linear's Create Issue action, select your Product team, then set Project to the Requests project you just created.
- 5
Map Feature Title to the issue title, and build the description from the problem statement first and the proposed solution second, so nobody reads a solution without its reason.
- 6
Add the workaround and the reach answers to the end of the description. Those two are what make a request arguable at planning rather than a matter of taste.
- 7
Set Labels to feature-request and Priority to Low, so incoming ideas never outrank committed work on the board.
- 8
Test with your sample submission, open the issue in the project view to check it reads properly, then turn 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 | Linear |
|---|---|
| Feature Title | Issue title |
| What problem does this solve? | Issue description, first section |
| What would you like to see? | Issue description, proposed solution |
| How are you working around it today? | Issue description, current workaround |
| Who else would benefit? | Issue description, reach note |
| How important is this to you? | Issue description, the requester's own rating |
Variations worth knowing
Ask on the form whether the requester is a customer or a colleague, then add a Zapier path for each answer. Customer requests go to the Requests project, internal ones to a Team ideas project, and roadmap review can weigh the two sources separately.
Leave every issue at Low priority and unassigned, then hold one session a quarter where the product team reads the project top to bottom. Duplicates get merged into a parent issue in Linear, and only the survivors are promoted into a cycle.
If something isn't arriving
The Project dropdown in Zapier is scoped to the team chosen in the step above it. If your Requests project belongs to a different Linear team, it will not be listed at all — switch the team on the action step and reselect the project.
Nothing deduplicates on the way in, and it should not: repeat requests are a signal. Sort the project by title during review and merge repeats into one parent issue, and each original wording still sits in your formformform responses.
Frequently asked questions
Will customers see our roadmap if they submit a request?
No. They only ever see the form. The issue is created inside your Product team, and Linear stays private to your workspace, so you can gather ideas without exposing what you have decided to build or the order you plan to build it in.
Should requests get their own team or just a project?
A project inside your Product team is enough for most people. Requests inherit the team's labels and cycle settings, and an accepted one can move into the roadmap without changing teams. Create a separate team only when a different group does the triage.
How do I stop requests taking over the sprint?
Set Priority to Low on the action step and leave the issues unassigned. They accumulate in the Requests project without appearing in anyone's active cycle, and a request only enters a sprint when someone deliberately moves it there.
Related automations
- Create design tasks from a campaign brief
Each brief becomes a Design team issue in the right project, with the campaign context already in the description.
- Route customer feedback into a triage view
Feedback arrives in Triage as a labelled issue the team can accept, decline, or move into a project.
- Send bug reports to your engineering backlog
Each report arrives in the Engineering backlog as a bug-labelled issue with reproduction steps already written.
- Send internal IT requests to your operations team
Hardware, access and tooling requests become assigned Operations issues with a priority, so the queue stays visible.
- Turn support escalations into tracked issues
Complaints that need an engineering fix become prioritised, customer-labelled issues in your Support team.
- 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