Zendesk Email Parser for Custom Ticket Fields: Ways Compared
Try it now: extract email data to Excel, CSV, or JSON
Connect a Gmail or IMAP mailbox to parse new mail automatically, or paste an email below to test the converter now.
Create a free account to download. No credit card required.
There are five working ways to get a value out of an email body and into a Zendesk custom ticket field, and native triggers are the weakest of them. Zendesk creates the ticket, keeps the subject as the ticket subject and the body as the first comment, and matches the sender to a user. It does not pull an order number, an account ID or a serial number out of that body and write it to a field. Triggers can set drop-down, checkbox and date fields when a condition matches, but they cannot set a text field at all, and they match text rather than extract it.
That gap is why support leads end up here. If your queue is customers describing problems in their own words, none of this matters and you should skip it. If your queue is order systems, partner portals, warranty forms and monitoring tools sending the same layout every time, the most reportable data in every ticket is sitting in a comment box where no view, no SLA and no dashboard can reach it.
Fill Zendesk ticket fields from the email body, without regex
MailParse reads the support mailbox over IMAP, pulls the values you name out of the body and its HTML tables, and hands back one clean record per email as JSON or CSV. See the Zendesk email parser, then push the values through the Tickets API, Zapier or Make.
The five options, compared
Each row below solves the same job: an email lands on your support address and the ticket should exist with its custom fields already populated. Two options are native, two are Marketplace apps, and one moves the work upstream of Zendesk entirely.
| Approach | How the field gets filled | Fills text fields? | Who maintains it | Best for |
|---|---|---|---|---|
| Native triggers | A condition matches words in the ticket, then sets a fixed value you typed into the trigger | No. Drop-down, checkbox and date only | Your Zendesk admin | A handful of known categories, one trigger per value |
| Ticket Parser Extract Patterns (Knots) | Regular expressions you write, run against subject, body and readable attachments | Yes | Whoever owns the regex | Stable formats and admins comfortable with patterns |
| Ticket Parser Autofill (Swifteq) | Parse and autofill workflows read ticket comments and populate fields | Yes | The app vendor, plus your workflow config | Teams that want the work inside Zendesk with less pattern writing |
| Webhook plus the Tickets API | Your own service reads the comment, extracts values and PUTs them back to the ticket | Yes | Your engineering team, forever | Logic too complex for patterns, or data that must be enriched first |
| Parse the mailbox before Zendesk | A parser reads the mailbox, returns named fields as JSON or CSV, and you post them in | Yes | The parser vendor, configured by a non-developer | Templated senders, HTML tables, and reporting outside Zendesk too |
Can Zendesk extract data from the email body?
No. Zendesk stores the email body as the ticket comment and can match conditions against its text, but it has no native function that pulls a substring out and writes it to a field. If a customer emails "Order 48213 arrived damaged," Zendesk will happily route and tag that ticket, and it will still leave 48213 inside the comment where no view or report can group by it.
Can a Zendesk trigger set a text field?
No. Triggers can set drop-down, checkbox and date custom fields, but text custom fields cannot be populated by a trigger. That single limitation is the reason most teams reach this question, because order numbers, account IDs, tracking numbers and serial numbers are almost always modeled as text.
The workaround people try first is a drop-down instead of a text field, with a trigger per value. That works when the set is small and known, such as five product lines or three regions. It falls apart the moment the value is unbounded, because you would need one trigger per possible order number.
How do I automatically fill a ticket field from the email body?
Pick based on how the value varies. If it comes from a fixed list, use triggers. If it follows a strict pattern in a stable template, use a regex parser app. If the format drifts between senders, or the value lives inside an HTML table, extract it before the ticket is created and pass it in with the ticket. The last route is the only one that survives a sender redesigning their template.
How do I parse an external ID from the mail subject or body?
An external ID is the easiest case and the most common request. It usually sits on its own line with a stable label, so a regex app handles it well. The trap is threading: if the same ID should attach a new email to an existing ticket rather than opening a fresh one, you need the value before the ticket exists, which pushes you toward parsing the mailbox or a webhook that runs on create.
Which option fits which support queue
Queues that are mostly human prose do not need any of this. Turning on a parser for a queue where every message is written differently produces empty fields and a false sense of structure, which is worse than no field at all.
Queues fed by machines are the opposite. A returns portal, a marketplace order system, a warranty registration form and an uptime monitor each send an identical layout thousands of times. Those are the queues where filled fields change how the team works: you can build a view for high-value orders, report on failure codes by product, and route by region instead of reading every ticket. Once the fields exist, routing them to the right agent becomes a rules problem rather than a reading problem, which is what dedicated task assignment software is built to do.
The mixed queue is the hard one. Most teams end up splitting it: a dedicated support address per automated sender, so the parser only sees mail it can actually read, and the general address stays untouched.
What parsing the mailbox before Zendesk looks like
The shape is simple. You connect the mailbox over IMAP, name the values you want such as order_number, account_id or total, and the parser returns one record per email. From there you create or update the ticket through the Zendesk Tickets API, or hand the record to Zapier or Make if you would rather not write the call yourself.
Two details matter more than people expect. The first is HTML tables. A shipping notification or an order summary usually puts its detail in a real table, and a ticket comment flattens that layout into a wall of text that regex struggles with. A parser that reads the table as rows and columns gets you clean line items, which is the same problem covered in extracting a table from an email. The second is that you keep the data outside Zendesk as well. Because the output is JSON or CSV, the same parse feeds a finance spreadsheet or a warehouse system without anyone exporting tickets by hand, which is how teams handle order data from email generally.
If you would rather push messages yourself instead of connecting a mailbox, the email parser API takes a raw email and returns structured JSON, which slots neatly into an existing webhook you already run.
Questions support leads ask before choosing
Will this work for tickets that already exist? Marketplace apps and API approaches can backfill existing tickets, because they read comments that are already stored. Parsing upstream only affects mail that arrives after you switch it on, so plan a one-time backfill if history matters to your reporting.
What happens when a sender changes their template? Regex breaks silently and keeps writing empty fields until someone notices. Field-name parsing degrades more gracefully because it is looking for labeled values rather than exact character positions, but nothing is immune. Whichever route you take, add a view for tickets where the key field is empty and check it weekly.
Do we still need a developer? Only for the webhook and API route. Triggers and Marketplace apps are admin work. Parsing the mailbox is admin work too, up until the point where you post the values into Zendesk, and Zapier or Make covers that step without code.
Is this the same problem other help desks have? Yes, almost exactly. Salesforce Email-to-Case drops the entire body into Description and fills nothing else, which is why the Salesforce email parser page walks through the same five-way decision for Service Cloud teams.
The short answer
Leave human-written queues alone. Use triggers when the value comes from a short fixed list. Use a Marketplace parser app when the format is stable and you want the work to stay inside Zendesk. Build the webhook when the logic genuinely needs code. Parse the mailbox when your senders are machines, the layout includes tables, and you want the same structured data in a spreadsheet as well as in the ticket. Most teams with a templated queue land on that last option, because it is the only one that gives them the values in both places at once.