Open internal IT requests as prioritised tickets
Staff IT requests become prioritised tickets on your internal Zendesk queue, with the device and issue type already on them.
New submission on your "IT request" form
Create a Zendesk ticket in your internal IT brand or group, with the request type as the subject, details in the description, and Priority set from the form
One-directional. A submission triggers the action — nothing is written back into your form.
An internal help desk fails on the intake, not the fix. Requests arrive as chat messages, corridor conversations and half a sentence in a group thread, and none of them carry the device name or when the problem started. A form asks for both before the request is accepted.
IT teams already running Zendesk for staff use this to close the last gap. Every request becomes a ticket in the internal group with priority set, so the board reflects the real workload rather than whatever someone remembered to log.
Setting it up
- 1
Publish the "IT request" form on an internal link, and use conditional logic so a broken laptop asks different questions from an access request.
- 2
In Zapier, set the "New Submission" trigger to that IT form specifically.
- 3
On the Zendesk action, choose the brand your internal help desk runs under. If you use a single brand, set the IT group on the step instead.
- 4
Map Work Email to the requester email so the ticket belongs to the staff member rather than to whoever set the Zap up.
- 5
Build the subject from Issue Type followed by Ticket Subject, so a view shows the category and the person's own wording side by side.
- 6
Map the form's Priority field straight onto Zendesk priority, and agree internally what Urgent means before publishing — otherwise everything arrives Urgent.
- 7
Send Department to an organisation or a custom field so requests can be routed and counted by team later.
- 8
Test from a staff account that holds no agent seat, confirm the requester resolves and the ticket appears in the IT view, then turn the Zap on.
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 | Zendesk |
|---|---|
| Issue Type | Prefix on the ticket subject, and a routing tag |
| Ticket Subject | Ticket subject, after the issue type prefix |
| Priority | Ticket priority on the Zendesk step |
| Issue Description | Ticket description |
| Work Email | Requester email — resolves to the staff member's Zendesk user |
| Affected Device or System | Custom ticket field the IT view groups on |
Variations worth knowing
The Zendesk help centre shows every requester a list of their open tickets. Because the ticket is created against their work email, a request submitted through the form appears there with no extra setup, and the chase-up message stops arriving an hour later.
New starter setup and a dead laptop want different handling. Branch on Issue Type in Zapier and send the two down separate paths — one to the provisioning group with a due date, the other into the live IT queue at whatever priority was chosen.
If something isn't arriving
The requester was created as a new end user rather than matched to the existing one. Map Work Email exactly, and make sure staff submit with the address they sign in to Zendesk with — an alias quietly creates a second user with no history.
A free choice of priority with no definition beside it drifts upward. Put the criteria in the field's help text on the form, or cap the mapping at High in Zapier and let agents raise anything genuinely worse once they have triaged it.
Frequently asked questions
Can I run an internal help desk on the same Zendesk as customer support?
Yes, using a separate brand or at minimum a separate group, so staff tickets never surface in a customer view. Keep the form on an internal link as well, or the URL circulates and outside requests start landing in the staff queue.
Do staff need a Zendesk login to submit a request?
No. The form is the front door and the ticket is created through the connection rather than by the person submitting. A login only matters afterwards, if you want them to follow progress in the help centre themselves.
Why use a form when we already have an IT email address?
An address takes whatever someone types. A form asks for the device, the start time and the priority every time, so the first agent to open the ticket already holds what they need instead of writing back to ask for it.
Related automations
- Capture webinar questions as tagged tickets
Questions from webinar registrations open as tickets tagged with the event, ready for the host to answer from one view.
- Collect post-support feedback as low-priority review tickets
Post-support feedback lands as a low-priority tagged ticket in a review view, out of the queue agents work each day.
- Log bug reports as prioritised Problem tickets
Each problem report becomes a Problem ticket in Zendesk, tagged and already carrying the priority the reporter chose.
- Route order and refund requests to the Billing group
Order and refund questions open in the Billing group with the order number already on the subject line.
- Send contact form messages to your support queue
Messages from your contact form open as Zendesk tickets, with a status, a group and the sender already resolved as the requester.
- Capture feature requests as labelled tickets
Product ideas from your feedback form land in Freshdesk as Feature Request tickets the team can group and revisit.
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