Create Jira Issue From Email: Parse Email Data Into Jira

Get the fields Jira leaves empty

MailParse turns each email into named columns (customer, order ID, severity, due date) you can map straight into Jira fields. Parse an email to CSV, then import.

Jira can create issues from email out of the box, but it drops the whole message into the description and leaves your custom fields empty. The built-in mail handler in Jira, and the email request channel in Jira Service Management, map the subject to the summary and the body to the description. That is fine for a support request. It is not enough when the email contains a purchase order number, a customer ID, or a severity level that needs to land in its own Jira field so you can filter, route, and report on it.

Getting those values into fields is the real job, and there are two honest ways to do it.

Last updated July 2026.

Can Jira create issues from email?

Yes. Jira Service Management has an email request channel: point a mailbox at the project, and each incoming message becomes a request with the sender as the reporter. Jira Software offers an incoming mail handler an administrator configures. In both cases the mapping is the same and fixed: subject becomes summary, body becomes description, attachments come across as attachments.

Why do my Jira custom fields stay empty?

Because nothing has parsed the body. Jira's mail handler is a transport, not an extractor. It knows the message arrived, and it copies the text across wholesale. It has no idea that the line "PO: 44821" in the middle of the body is a purchase order number that belongs in your PO custom field, so that field stays blank and your board cannot be grouped by it.

The two ways to populate Jira fields from an email

What matters	Jira Automation with a regex rule	Parse first, then import or map
How it works	An automation rule reads the description and pulls values out with a smart value regex	A parser turns each email into named fields, which you load into Jira
Who sets it up	A Jira admin comfortable with regex	The person who owns the process
Handles an HTML table of line items	Poorly, regex over a flattened description gets ugly fast	Yes, each table row becomes its own row
When a sender changes their template	The regex silently stops matching	Adjust the field mapping
Bulk history (a year of old emails)	No, it only runs on new issues	Yes, parse the mailbox and import the CSV
Best for	One or two simple values in a consistent, machine-generated email	Several fields, messy senders, or a backlog to load

Credit to Jira here: if every email comes from your own system in an identical format and you need exactly one value, an automation rule with a regex is free, native, and the right answer. Reach for parsing when the senders are humans, the layouts vary, or you have more than a couple of fields.

How do I import parsed email data into Jira?

Jira has a CSV importer, reachable as an external system import for a site admin or as a project-level CSV import. It maps each column in your file to a Jira field, including custom fields, and creates one issue per row. That is the lever most people miss, and it makes the workflow simple.

Connect the mailbox to MailParse, name the fields you want (summary, reporter email, order ID, severity, due date, anything sitting in the body), and export a CSV. In Jira, run the import and match each column to its field. Custom fields populate because you handed Jira a column for each one, instead of asking it to guess from a wall of text. If you would rather push the data into a system that speaks JSON, the email to JSON converter gives you the same fields in a structured payload.

How do I create a Jira issue from an Outlook email?

Forwarding it to the project's email address works and gives you the default mapping, summary and description only. To get more, parse the mailbox instead of forwarding message by message. Connect the Outlook or Microsoft 365 account, let the Outlook email parser read the messages, and export the columns you need. Mail on a host that is not Google or Microsoft is fine too, over a standard IMAP mailbox connection.

What about the attachments on the email?

Jira's mail handler does bring attachments across onto the issue, which is genuinely useful and worth using. Be clear about what a parser adds and what it does not. MailParse reads the email itself, its headers, body, and HTML tables, and records each attachment by filename, type, and size. It does not read what is inside a PDF. If the values you need live inside an attached document rather than in the message text, that is a document extraction job and a different tool.

A practical setup for a service desk

Keep Jira's email channel switched on, because losing the ability to raise a ticket by email would be a downgrade. Run the parser alongside it for the data layer. Point the parser at the same mailbox, map the fields your team actually filters on, and load them. Tickets keep arriving the way your customers expect, and your board finally has the columns your reports need.

Where the incoming mail is machine generated, this pays off fastest. Monitoring alerts are the clearest case: they arrive in a rigid format, they carry the host, the check, and the timestamp in the body, and those three values are exactly what you want as Jira fields rather than as prose. If you do not have that coverage yet, a service that checks your sites and APIs every 30 seconds gives you alerts worth parsing in the first place.

Related routes into other systems

The same parse-then-map pattern works wherever the destination accepts structured input. The walkthroughs for parsing email into ServiceNow and parsing email into Salesforce follow the same shape, and the email to CRM page covers pushing parsed messages into a customer record. Start by seeing which fields come back from your own tickets with the email to Excel parser.