Log every support request as a new ticket record
Each help desk submission opens a Tickets record with priority, description and requester email, its status already set to New.
New form submission
Create a record in the Tickets table with status set to 'New'
One-directional. A submission triggers the action — nothing is written back into your form.
Email intake hides the shape of the queue. Nobody can tell how many tickets are open, which are urgent, or who has picked one up. Routing a help desk form straight into an Airtable Tickets table gives every request the same columns from the moment it arrives.
Small support and IT teams tend to set this up after the first request goes missing. Setting Status to New inside the Zap, rather than leaving it blank, means a grid view filtered to New is a real queue on day one, and grouping by Priority shows what to pick up next.
Setting it up
- 1
Publish the help desk form and make Priority and Issue Description required — an unprioritised ticket cannot be sorted into a queue.
- 2
In your support base, build the Tickets table with a Status single-select whose first option is New, and a Priority single-select whose options match the form's Priority choices word for word.
- 3
In Zapier, choose formformform, the New Submission trigger and your help desk form, then load a sample submission so the mapping boxes show real values.
- 4
Add the Airtable Create Record action, connect the account, and pick the support base and its Tickets table.
- 5
Map Ticket Subject to the primary field of Tickets so each row is readable wherever it is linked, and Issue Description to a long text Details column.
- 6
Type New straight into the Status field in the Zap instead of mapping anything to it, so every ticket enters the queue in the same place.
- 7
Map Work Email to a Requester Email column and Priority to the Priority single-select, and leave the Assignee collaborator field unmapped for an agent to claim.
- 8
Run one test submission at each priority level, confirm each row lands with Status New, 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 | Airtable |
|---|---|
| Ticket Subject | Primary field of the Tickets table |
| Issue Description | Details long text column |
| Priority | Priority single-select |
| Issue Type | Category single-select |
| Work Email | Requester Email column |
| Affected Device or System | Device text column |
Variations worth knowing
Use Zapier Paths on Issue Type: one path creates a record in Tickets, the other in an Equipment table where rows carry an asset tag and a location. Both paths still type New into their own Status column, so each queue reads the same way. Keep the paths mutually exclusive or a single submission will land twice.
Map "When Did the Issue Start?" to a date column called Started, then add an Airtable formula field comparing it with the record's created time. Sorting by that field surfaces problems that have been quietly going on for a week, which the Priority a requester picks for themselves often understates.
If something isn't arriving
Airtable drops a single-select value it does not recognise instead of failing loudly. Compare the form's Priority choices with the Airtable options side by side — a trailing space or "High" against "High priority" is enough to break the match. Fix the option text, then re-run the failed tasks from the Zap history.
The Details column is a single line text field, which keeps only what fits before the first line break. Change it to Long text in Airtable and re-send a test submission with several paragraphs to confirm the whole description arrives intact.
Frequently asked questions
Can agents edit a ticket in Airtable without breaking the Zap?
Yes. The Zap only ever creates records; it never reads the table back or reconciles it. Change the status, reassign the ticket, rewrite the summary — the next submission is unaffected, because each run works from the form response alone.
What happens to requests submitted while the Zap is switched off?
The response is still stored in formformform, so nothing is lost. No Airtable record is created for it, though. Turn the Zap back on, then export the missed responses from your submissions view and paste them into the Tickets grid.
Do we need a separate form for each priority level?
No. One form with a Priority single-select covers it, and the value carries through to the Airtable column so views can group by it. Use Zapier Paths only when different priorities genuinely need different actions, such as writing to a separate escalation table.
Related automations
- Add job applicants to a hiring pipeline
Each application becomes a Candidates record with role, start date and stage, ready to drag through a kanban view.
- Capture demo requests as leads in a CRM base
Every demo request becomes a Leads record with name, company, work email and source, ready for an owner and a status.
- Collect event RSVPs as attendee records
Each RSVP becomes an Attendees record with guest count and dietary notes, stamped with the event date.
- Store product feedback with a rating for triage
Every response lands in a Feedback record with the rating, the product and the verbatim comment, ready to group by theme.
- Turn pre-orders into linked records in an inventory base
Every pre-order writes an Orders record with quantity and customer details, linked to the matching product row.
- Add every inbound enquiry to your Notion leads database
Every business enquiry lands in your Notion Leads database as a page tagged New, with the company and inquiry type already filled in.
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