How to Create a Zendesk Ticket From an Email, Fields Included

The short answer: add a support address in Zendesk and forward your support inbox to it. Every message that arrives becomes a ticket automatically, with the sender matched to a requester and the body attached as the first comment. That part takes about five minutes and needs no code. What it will not do is take the order number sitting in the third line of that email and put it on your Order Number custom field, and that is usually the part people are actually asking about.

How do I create a Zendesk ticket from an email?

Zendesk treats email as a first-class channel, alongside the help center, chat, phone, and the API. Turning it on is a configuration step rather than a build:

1. In Admin Center, go to Channels and then Email, and add a support address. You either use the default address Zendesk gives you on your subdomain, or add your own domain address such as [email protected].
2. If you added your own address, forward that mailbox to the Zendesk address and verify it. Zendesk checks that forwarding works before it starts accepting mail on that address.
3. Set your SPF, DKIM, and DMARC records so replies sent from Zendesk on your behalf authenticate properly. Skip this and your outbound agent replies start landing in spam, which is a much bigger problem than it sounds.
4. Send a test message. It arrives as a ticket with the subject as the ticket subject, the sender matched to an existing requester or created as a new one, and the body as the first public comment.

From there triggers can route it, tag it, assign a group, and set an SLA target. That workflow layer is genuinely good and there is no reason to replace it.

Why does the ticket arrive with an empty custom field?

Because nothing filled it in. This trips up almost everyone the first time. You create a custom ticket field called Order Number, you watch order emails flow in, and every single ticket shows that field blank even though the order number is right there in the message.

Zendesk parsed the email only as far as it needed to in order to open a ticket. It identified who sent it, what the subject line was, and it attached the body. It did not read the body. There is no step in the email channel that looks at the content and decides which of your custom fields the words inside it belong to.

Can a Zendesk trigger read a value out of the email body?

No, and this is the specific limit worth understanding before you spend a day trying. A trigger in Zendesk is a condition plus an action. The condition can check whether the description contains the text "refund", and the action can set a custom field to a fixed value you chose when you built the trigger. That combination is powerful for categorization.

What it cannot do is capture. There is no action that means "take the digits that follow Order # and write them into the Order Number field". The value has to already be known to you at build time. Automations and macros have the same shape and the same limit. Anything that needs the literal, varying value out of the message requires either a person reading it or code.

Zendesk's intelligent triage moves the line a little, and it deserves credit. It predicts things about a ticket such as intent, language, and sentiment, and routing on those predictions works well. But prediction is classification, not extraction. It will tell you a ticket is about a refund. It will not hand you the order number.

How to fill Zendesk custom fields from an email

The working pattern is to parse the message before or alongside Zendesk, then write the fields onto the ticket through the API. Four steps:

1. Connect the mailbox to a parser. Point an email parser at the same Gmail, Outlook, Microsoft 365, or IMAP inbox your support mail lands in, or forward a copy to a parsing address. It reads the messages in parallel with Zendesk; you are not replacing the support address.
2. Name the fields you want. Describe each value once: order_number, account_id, serial_number, return_reason, invoice_total. A parser that works off named fields rather than fixed character positions keeps reading them when a sender reorders their template, which they will.
3. Get the field IDs from Zendesk. Call GET /api/v2/ticket_fields and note the numeric id of each custom field you created. You need these because the API addresses custom fields by ID, not by title.
4. Post the ticket with the fields attached. Send the parsed values to POST /api/v2/tickets with a custom_fields array. Each entry is a field id and its value.

The payload looks like this:

{
  "ticket": {
    "subject": "Refund request for order 48213",
    "comment": { "body": "..." },
    "custom_fields": [
      { "id": 360001234567, "value": "48213" },
      { "id": 360001234568, "value": "damaged_in_transit" }
    ]
  }
}

If you are clearing a backlog rather than handling live mail, POST /api/v2/tickets/many takes a batch in one call and returns a job you poll for status. That is the right endpoint for importing a few thousand parsed messages, not a loop over the single-ticket endpoint.

Do I have to write code to do this?

Not necessarily. The API route is the most direct and gives you the most control, but if nobody on the team wants to own a script, Zapier and Make both have Zendesk connectors that create a ticket and set custom fields. Point the parser's webhook at the automation, map each parsed field to the matching Zendesk field in the connector's dropdown, and you get the same outcome with no deployment.

The tradeoff is per-task pricing and one more service in the chain. At a few hundred tickets a month it is cheap and perfectly reliable. At tens of thousands, the direct API call is both faster and less expensive, and by that volume you probably have someone who can maintain twenty lines of code.

What about data inside attachments?

Worth being clear about this, because it is where a lot of support mail actually keeps its data. Zendesk attaches files to the ticket so an agent can open them. An email parser reads the message body and its HTML tables, and records each attachment by filename, type, and size, but it does not open a PDF or a spreadsheet and read what is printed inside.

When the invoice number you need only exists inside an attached PDF, that is a document extraction job rather than an email parsing one. Run the file through a tool built to read documents first, then merge that output with the fields the parser pulled from the body. Two steps, but each one uses the right tool.

What if the email contains a table?

This is the case that breaks every manual workaround. A return authorization or a supplier notice often arrives as an HTML table: five rows, each with a SKU, a quantity, and a reason. Zendesk renders that table for the agent to read, which is fine for a human and useless for reporting. Copying it into a spreadsheet by hand collapses the columns.

A parser that understands HTML tables returns one record per row, so you can either open a ticket per line item or attach the whole set as structured data. The mechanics of that are covered in extracting a table from an email without breaking the columns.

When is native Zendesk enough?

Often, and it is worth saying so plainly rather than selling a parser to someone who does not need one. If your tickets are conversations, a customer describing a problem in their own words, then there are no fields to extract and adding a parser buys you nothing. The same is true if your requests arrive through a help center form, because a form already collects values into fields by design. Route the form, skip the parsing.

Volume matters too. Ten structured emails a day is a two minute copy and paste job. It only becomes worth automating somewhere north of a few dozen, or when the value has to be right every time because routing and SLA targets depend on it. And if the bigger problem is not the fields but the sheer number of repetitive questions reaching a human at all, the answer is deflection rather than extraction: software that answers the routine ones outright keeps them off the queue instead of filling in a field faster.

Where this leaves you

Zendesk owns the ticket: threading, requester matching, SLAs, routing, the whole agent workflow. None of that needs replacing and a parser does not try to. What a parser adds is the one step missing between an email landing and a ticket being useful, which is turning the content of the message into values a field can hold.

Set the support address up first, since it costs nothing and you need it either way. Then look at how many of your tickets arrive with a reference number an agent has to hunt for. If that number is large, the email parser Zendesk integration covers the setup end to end, and the email parser API shows the JSON shape you will be posting. Running the same problem in a different tool? The approach is close to identical for ServiceNow and for creating Jira issues from email.