Open a help-desk ticket and set its priority
One submission creates the ticket, sets its priority from the answer the requester picked, and drops a summary into the support channel.
New submission on your support form
Trigger a Make scenario that creates a help-desk ticket, sets priority from the urgency field, and posts a summary to the support channel
One-directional. A submission triggers the action — nothing is written back into your form.
Support requests arrive with the urgency already stated in them. The person filling in the form has picked a priority, described the fault and named the machine it happens on. This flow takes that at face value: the Make scenario creates the ticket, sets its priority from the answer, and posts a short summary where agents are already looking.
Internal IT teams reach for it when the help-desk inbox and the chat channel have drifted apart, and a request logged in one is invisible in the other.
Setting it up
- 1
Publish the IT help desk form and make Priority a fixed choice list whose option names match the priority values your help desk accepts, word for word.
- 2
In Make, start a scenario with a custom webhook module so the Zap has somewhere to deliver the submission.
- 3
Add your help-desk module set to create a ticket, mapping the subject and description first and leaving priority until the field types line up.
- 4
Add a filter after the ticket module that only continues when Priority is your top option, then put the channel-post module behind it so routine tickets ping nobody.
- 5
In Zapier, pick formformform and the New Submission trigger, connect the account and select the help desk form.
- 6
Add Make as the action app, point it at this scenario's entry point, and map Ticket Subject, Issue Description, Priority, Issue Type and Work Email.
- 7
Submit one low-priority and one urgent test request, then read the execution history: both should create a ticket, only the urgent one should reach the channel.
- 8
Turn the Zap on, then watch the first day of real tickets for priorities that arrive blank.
What maps where
Using the IT Help Desk Ticket as the starting point. These are its real fields — swap in your own and the mapping works the same way.
| Form field | Make |
|---|---|
| Ticket Subject | Ticket title in the help-desk module |
| Issue Description | Ticket body, and the text quoted in the channel summary |
| Priority | Priority field on the ticket, and the filter deciding whether the channel post runs |
| Work Email | Requester email the help-desk module matches to an existing user |
| Issue Type | Ticket category or queue |
| Affected Device or System | Asset line appended to the ticket body |
Variations worth knowing
Swap the filter condition from Priority to Department when teams have their own queues. Finance requests reach the agent who knows the finance systems, everything else goes to the general queue, and priority is left to set the ticket field only.
Keep a data store of machines and their owners, then look up Affected Device or System before the ticket is created. The scenario can add the owner and the location to the ticket body, which saves an agent asking for it in the first reply.
If something isn't arriving
The help-desk module rejected an unrecognised value and fell back. Compare the exact option text in the form with the priority names the help desk expects, and map through a Make switch function when the two sets cannot be made identical.
The scenario ran twice, usually because a failed run was retried from incomplete executions after the ticket had already been created. Move ticket creation behind a data store check keyed on the submission ID so a second run updates rather than creates.
Frequently asked questions
Can the requester see the ticket number on the form after submitting?
No. Nothing travels back from Make into the form, so the confirmation screen cannot show a number the help desk has not issued yet. Put the ticket number in the acknowledgement email your scenario sends instead, once the ticket module has returned it.
What happens to requests submitted while the scenario is switched off?
The submission is still saved in formformform and the Zap still fires, but a paused scenario will not run, and Zapier records the failure. Re-run those tasks from Zapier's history once the scenario is live again and the tickets will be created.
Should priority come from the form or be worked out in Make?
Take it from the form when the requester picks from a fixed list, which is what the Priority question gives you. Work it out in Make when priority depends on something the requester cannot know, such as a department's service level or how critical the affected system is.
Related automations
- Confirm event sign-ups and log the attendee
A registration becomes a calendar entry, a confirmation email and an attendee row, all from one scenario run.
- Filter job applicants before they reach your ATS
A Make filter checks education and skills before the ATS sees the applicant, so the pipeline fills with people worth calling.
- Record each order and start fulfilment
Every order is recorded in a data store, turned into an invoice, and passed to whoever picks and packs it.
- Route new leads down enterprise and nurture paths
Each lead enters a Make scenario where a router reads company size and sends enterprise deals one way, everyone else another.
- Tag feedback by score and alert on detractors
Every score is banded and logged in a data store, and anything under your threshold alerts the team straight away.
- Let only qualifying applications reach the hiring manager
A Filter step checks location and hours first, so only qualifying applications create a candidate record and reach the hiring manager.
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