Push support requests onto your own job queue
Every support submission is posted to an endpoint that enqueues the request and sets its priority from the answer on the form.
New submission on your support form
POST the payload to an endpoint that enqueues the request on your job queue and assigns a priority from the urgency field
One-directional. A submission triggers the action — nothing is written back into your form.
Support intake handled in-house tends to fail in the same place: the request arrives somewhere a person has to read it before anything can happen. This flow posts each submission to a route that pushes a job onto your queue, so triage starts without anyone copying a ticket across by hand.
Engineering teams that already run workers for everything else use it to treat support like any other job. The Priority answer becomes the queue priority, so an outage does not sit behind ten password resets.
Setting it up
- 1
Publish your help desk form with Priority required, and keep its options to the small set your queue actually understands.
- 2
Add a POST route — /webhooks/tickets — that reads the JSON body and returns 200 without enqueuing anything yet.
- 3
Enable the outgoing webhook in the form's settings, paste the route's full URL, and save the form.
- 4
Send a test ticket and log the body so you have the exact keys for Priority, Issue Type and Ticket Subject.
- 5
Map each Priority option to a numeric queue priority in one lookup table in the handler, with an explicit default for a value you do not recognise.
- 6
Enqueue the job with Ticket Subject as its display name and Issue Description in the payload, so a worker can triage without a second lookup.
- 7
Use Issue Type to pick the queue or routing key, so hardware faults and access requests reach different workers.
- 8
Return 2xx after the broker acknowledges the enqueue, never before — otherwise a broker outage is recorded as a successful delivery and the ticket is gone.
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 | Webhooks |
|---|---|
| Priority | queue priority, via a lookup in your handler |
| Issue Type | queue or routing key the job is published to |
| Ticket Subject | display name on the enqueued job |
| Issue Description | body of the job payload |
| Work Email | requester field on the job |
| Affected Device or System | asset reference stored with the job |
Variations worth knowing
Rather than enqueuing every job immediately, write the lowest Priority band to a table and let a scheduled worker drain it hourly. Urgent tickets keep their own path and stay instant. It stops a flood of routine requests pushing a real incident down the queue during a bad afternoon.
For the top Priority band, call your alerting API from inside the route once the enqueue succeeds. After, not instead: the job still needs to exist for the record. Keep the page conditional on Issue Type too, so a printer someone marked urgent does not wake anyone at 3am.
If something isn't arriving
Your lookup is matching on something other than what arrives — a value rather than a label, or a string with different casing. Log the Priority value from one real submission, compare it character for character with the keys in your map, and add a default for anything that misses.
The route is returning 2xx before the broker has acknowledged the publish, so a dropped connection looks like success. Await the acknowledgement and return a 5xx when it fails, so the delivery is recorded as failed rather than logged as a ticket you never actually received.
Frequently asked questions
Can the form show the requester a ticket number?
No. The webhook runs one way: the submission goes out to your endpoint and nothing your handler generates comes back into the form. If a requester needs a reference, email it from your own system once the job has been enqueued.
What happens if my queue is down when a ticket is submitted?
Your route decides. Return a non-2xx and the delivery is recorded as failed, which tells you a ticket needs replaying. Writing the raw body to a durable table first and enqueuing after is safer: the request survives a broker outage and a worker picks it up later.
Why put support intake on a form instead of an inbox?
A form gives you a Priority and an Issue Type on every request, which an inbox does not. That is what makes automatic routing possible — your handler has structured values to branch on instead of a subject line someone typed at midnight.
Related automations
- Deliver job applications to your hiring service
Every application is posted as JSON to your applicant tracking service, which validates the fields before it creates a candidate.
- Fan event sign-ups out to your own services
One POST per RSVP writes the attendee to your database and publishes a message the rest of your services can listen for.
- Send custom orders to your fulfilment backend
Each order submission is posted to your orders API, which records the items and starts fulfilment with nothing rekeyed by hand.
- Stream feedback scores into your analytics pipeline
Each NPS response is posted to an ingestion endpoint that normalises the score and streams the record into your warehouse.
- Write new leads straight into your own database
Each lead capture submission reaches your endpoint as JSON and becomes a row in your own leads table, seconds after it is sent.
- Alert the on-call team when a support ticket arrives
Each new ticket posts to #support with its subject and priority, and @here fires only when the priority justifies interrupting a shift.
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