Parse Email into ServiceNow: Fields, Tables & Records
Last updated August 2026
Try it now: extract email data to Excel, CSV, or JSON
Connect a mailbox to pull .eml/.msg in bulk, or paste a raw email to test the converter now.
Create a free account to download. No credit card required.
An inbound email action creating the record but not the fields you need?
ServiceNow can open an incident or request from an email, but extracting structured fields means scripting the inbound action, and it flattens HTML tables into plain text. MailParse reads the full body and HTML table rows, pulls out the fields you name, then hands you clean CSV or JSON to load into ServiceNow. See the ServiceNow email parser approach, or read the full guide below first.
ServiceNow is good at getting an email into the platform. An inbound email action or a Flow Designer email trigger turns a message into an incident, a case, or a catalog request, and the sender, subject, and a copy of the body land on the record. What it does not do without help is pull the structured values out of that message: the asset tag in the third line, the purchase order number sitting mid-body, or the rows of an alert table. This guide is a practical look at what native ServiceNow email handling covers, where it stops, and how to get the rest of your email data into ServiceNow as clean records.
Does ServiceNow have an email parser?
ServiceNow does not have a point-and-click email parser. It has inbound email actions and Flow Designer email triggers that can create an incident, case, or request from a message, with the sender, subject, and body copied onto the record. To pull structured values out of the body, you script the inbound action in JavaScript, or you build a Flow that slices the body with string functions. Both work, and both need a developer or an admin comfortable with code.
The boundary matters. Routing an email into a record is built in. Turning the contents of that email into named fields is custom work that you build and then maintain as your senders change their formatting.
How do I parse an email body in ServiceNow?
Natively you write a scripted inbound email action that reads email.body_text and slices it with JavaScript split, indexOf, and substring to find the values you want, then sets them on the record. A Flow Designer trigger can do a lighter version with string functions. Both read the plain text body, both are keyed to fixed text positions, and both assume name and value pairs sit on their own line.
The simpler route for varied mail is to parse the message in an external email parser first, name the fields you want, then load the result into ServiceNow as a CSV import or through the Table API. One setup then covers many senders and layouts without a script to redeploy.
How do I read the body text in an inbound email flow?
In a scripted inbound action the body is available as email.body_text for the plain text version and email.body for parsed name:value pairs. The catch is that email.body only populates fields when each pair is on its own line in a name:value format, so anything conversational, tabular, or HTML does not map cleanly. That is why so many teams fall back to splitting email.body_text by hand and walking the result.
An external parser sidesteps the format dependency by reading the fields you name wherever they sit in the message, including inside HTML tables, so you are not relying on a sender to keep their layout in the exact shape your script expects.
Can a ServiceNow inbound email action read attachments?
No. An inbound email action can attach an inbound file to the record it creates, so the PDF or spreadsheet is stored alongside the incident, but it cannot read what is inside it. The purchase order total in a PDF, the line items in an attached spreadsheet, and the details in a scanned document stay locked in the file. To get those into ServiceNow fields, the attachment has to be extracted before the data reaches the record.
MailParse parses the email body and HTML tables and records the filename of any attachment for reference, but it does not read the data locked inside a PDF or spreadsheet. When the real data arrives as a file, extract it first: a dedicated document OCR tool turns the scanned file into text and pulls the values out, and you feed that clean output into your ServiceNow import. For everything carried in the message itself, the parser handles it directly.
How do I parse a table in an email in ServiceNow?
Parsing an HTML table in ServiceNow means scripting that strips the markup and walks the rows, which is brittle and breaks when a sender changes their layout. Tables in emails with no colons or delimiters defining the cell boundaries are especially hard, because the inbound action has nothing reliable to split on. Many of the emails businesses receive, monitoring alerts, order confirmations, and request forms, carry their data in HTML tables where each row is a record.
An external parser reads HTML emails and repeating table rows directly, turning each row into its own clean record or spreadsheet line. That is the difference between one messy description field and a structured set of columns you can import into ServiceNow.
How do I import email data into ServiceNow?
Use an Import Set and a Transform Map with a clean CSV. Once an email parser has turned your messages into rows, with each field as its own column, you load the CSV into an import set table, map the columns to the target table fields once, and run the transform to create or update records in bulk. It is the fastest way to clear a backlog of emails into ServiceNow in one pass.
The requirement is a clean CSV to begin with, which is what the parser produces. If the data started life as a PDF report or attachment, a PDF to Excel converter takes that file to a spreadsheet first, and the resulting CSV imports the same way.
How do I create ServiceNow records from email automatically?
Send the parsed data as JSON to the Table API, a Scripted REST endpoint, or through Flow, Zapier, or Make. When the parser finishes a message it fires a webhook with the structured data, and a flow creates or updates a ServiceNow record for each email as it arrives. No CSV, no manual import, and no inbound action script to maintain, the record simply appears in the platform.
This is the setup for steady inbound mail: alerts from a monitoring tool, vendor confirmations, supplier requests. You name the fields once, point the webhook at your ServiceNow endpoint, and every future email lands as a record. Pair it with a one-time CSV import to handle both the backlog and everything new.
Inbound email action or an external parser: which to use
Match the tool to the mail. If you receive one consistent, plain-text email type with clean name:value lines, a scripted inbound action is the cheapest option and worth using. If you receive HTML, tables, or formats that vary between senders, an external parser does the work native handling cannot, then hands the result to ServiceNow through a CSV import or the Table API. Most teams use the native features for their tidy email types and a dedicated parser for everything else.
When you are ready to capture the body fields and table rows ServiceNow leaves as text, the ServiceNow email parser approach reads every message and gives you clean records to import or push into the platform. Teams routing the same inbound mail into a sales pipeline as well can point it at the broader email to CRM parser. If you would rather see the data as a spreadsheet, the email to Excel converter exports it directly, developers can pull structured records through the email parser API, and if you are still choosing a tool, the best email parser guide walks through what to compare.
Feeding a CRM instead of a service desk? The same named-field workflow applies when you parse email into Salesforce or parse email into Zoho CRM, and how to add email leads to your CRM automatically covers the end-to-end pattern.