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.
New submission on your "IT request" form
Create a Jira issue in your service project with the request type as the summary, the details in the description, and Priority mapped from the urgency field
One-directional. A submission triggers the action — nothing is written back into your form.
Internal IT requests arrive as chat messages, and chat messages scroll away. A short form in front of the team gives the queue a fixed shape — a change type, a system, a priority and a date someone needs it by — and the board keeps all of it.
The teams that adopt this are usually two or three people supporting a whole company, who need the board to answer what was agreed without anyone rereading a thread from last Tuesday.
Setting it up
- 1
Publish the change request form and keep it short. The fewer questions there are, the more likely people use it instead of messaging the team directly.
- 2
Open your Jira project's priority scheme and word the form's priority dropdown to match those names exactly, capitalisation included.
- 3
In Zapier, connect the formformform "New Submission" trigger to the form and load a sample submission.
- 4
Add "Create Issue" and select the service project the team works from. Leave Issue Type as Task unless the project uses its own request types.
- 5
Build the summary from the change type and the system name together, giving every issue a scannable shape such as "Access change — Salesforce".
- 6
Map the description of the change and the business impact answer into the issue description, keeping impact last so it reads as the justification.
- 7
Map the requested completion date to the due date and the priority answer to Priority, so the board sorts itself without anyone re-reading requests.
- 8
Submit one test request at each priority level to confirm the mapping holds, then turn the Zap on.
What maps where
Using the Software Change 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 |
|---|---|
| Change Type | First half of the Jira issue summary |
| Application or System Name | Second half of the summary, or a component |
| Priority Level | Priority field on the issue |
| Description of Change Requested | Issue description, main body |
| Business Impact if Not Completed | Description, justification section |
| Requested Completion Date | Due date on the issue |
Variations worth knowing
Add an approval question to the form and a Zapier filter that only continues when it is answered. Unapproved requests still record as submissions in formformform, they simply never reach the board.
Use paths on the change type answer: access requests create issues in the service project, code and configuration changes go to the platform project. One form, two boards, nothing typed in twice.
If something isn't arriving
Jira falls back to the scheme default when an incoming value matches no priority name. Check the exact spelling in Jira's project settings and make the form dropdown use those words, capital letters and all.
A summary built from two answers leaves a blank space rather than failing when one is empty. Make the system name a required question on the form so both halves of the summary are always present.
Frequently asked questions
Can requesters see where their request has got to?
Not through the form. Nothing is written back from Jira to formformform. Teams usually share a filtered Jira board or a dashboard link company-wide instead, so people can look their own request up by name.
What stops people bypassing the form and messaging us anyway?
The Zap cannot help with that, but a short form can. Six questions takes under a minute, and every request that comes through arrives with a priority and a deadline already stated, which is the argument for using it.
Can one form serve two different IT teams?
Yes. Branch on the change type with Zapier paths and give each path its own project and issue type. Conditional logic in the form can also hide the questions that only one of the two teams needs answered.
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 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