Email Parser Salesforce Integration: Salesforce Email Parser for Leads, Cases, and Custom Objects
Parse the fields and table rows out of the email body Salesforce leaves as text, then send clean records into Salesforce
Salesforce can route an inbound message into a Case or a Lead, but it does not parse structured fields out of the body without Apex code, and it flattens HTML tables into plain text. MailParse reads the full email body and HTML table rows, pulls out the fields you name, then exports clean CSV and JSON you import into Salesforce or push in as records through Flow, Zapier, or Make.
Last updated July 2026
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.
Salesforce's built-in Email-to-Case and Email-to-Lead capture the message, but they do not break the body apart into fields, so the values you actually want stay buried in the email text. A Salesforce email parser sits in front of that: it reads each inbound message, pulls the named values out of the body and any HTML table, and hands back a clean record. MailParse exports a CSV shaped for the Data Import Wizard, or JSON you can post through the API, Zapier or Make.
- Named fields
- Pulled from the body Salesforce leaves as text
- HTML tables
- Parses layout Salesforce flattens
- CSV / JSON
- Import or webhook into Salesforce
- No Apex
- Name fields, skip the code
Salesforce is good at getting an email into the system. Email-to-Case turns an inbound message into a Case, web-to-lead and email-to-lead create Lead records, and the email subject, sender, and body land on standard fields. What Salesforce does not do out of the box is pull structured values out of the message: the order number sitting in the third paragraph, the account ID a vendor buries mid-body, the rows of a shipment table, or a custom field a partner sends in their own layout. To extract those into Salesforce fields natively, you write an Apex class that implements the Messaging.InboundEmailHandler interface and parse the text yourself, or you build a Flow that slices the body with string functions. Both work, both take a developer or an admin comfortable with formulas, and both break when a sender changes their formatting.
MailParse is the external email parser that does the extraction part for you. Connect a Gmail, Outlook, Microsoft 365, or IMAP inbox, or forward a message to a parsing address, then name the fields you want such as order_number, case_reference, account_id, or tracking_number. MailParse reads them from the full body and from HTML emails with real tables that Email-to-Case flattens into a wall of text. You get a clean CSV, an Excel workbook, or JSON. If the values you need sit in a shipment or line-item table, extracting a table from an email covers what Email-to-Case flattens. From there you load the data into Salesforce the way that fits: import the CSV with the Data Import Wizard or Data Loader, or send JSON through Flow, Zapier, or Make to create or update a record per email automatically. MailParse records the filename of any attachment for reference; when the value you need is locked inside a PDF, extract the PDF with a document tool first, then feed the result in. This page is an honest look at where Salesforce native handling is enough and where an external parser does the work it cannot.
What the converter does
Everything you need to turn a pile of email files into a spreadsheet your team can actually use.
Pulls named fields the body hides
Email-to-Case drops the whole message onto one field. MailParse reads the order number, account ID, or case reference sitting mid-body and returns each as its own column, so the values you need arrive as data instead of a paragraph.
Parses HTML emails and tables
Pulling table rows out of an HTML email in Salesforce means Apex or fragile Flow string functions. MailParse parses HTML emails and repeating table rows, so order confirmations, reports, and lead forms come through as clean columns.
Name fields instead of writing Apex
A native parse means an InboundEmailHandler class or a body-slicing Flow. MailParse reads the fields you name across senders that format the same data differently, so one setup covers many layouts with no code.
Holds up when a sender changes format
Apex and Flow parsing keyed to fixed text positions break when a vendor renames a heading or reorders a line. MailParse keeps reading the named fields when the layout drifts.
CSV and JSON that load into Salesforce
Export a CSV for the Data Import Wizard or Data Loader, or send JSON through Flow, Zapier, or Make to create or update a record per email. The choice is yours, and the data is clean either way.
Spreadsheet output for everyone else
Not every email belongs in the CRM. Download a formatted Excel workbook or CSV for an accounting import, a report, or a teammate who just wants the numbers, without routing the data through Salesforce first.
How to parse email into Salesforce the data way
Four steps to capture the fields and table rows Email-to-Case and Flow leave as text.
Connect or forward
Connect the Gmail, Outlook, Microsoft 365, or IMAP inbox your Salesforce-bound mail arrives in, or forward a sample message to a dedicated MailParse parsing address.
Name your fields
List the values you want as records in Salesforce, including fields buried mid-body and columns inside HTML tables. Describe each field once instead of writing an Apex parser or a Flow formula.
Choose CSV or JSON
Export a CSV for the Data Import Wizard or Data Loader, or point JSON at Flow, Zapier, or Make to create or update a record per email automatically.
Load and reuse
Run a backlog in one pass and let new mail flow in automatically. Adjust the fields anytime from a form, with no Apex to redeploy when a sender changes their layout.
Who outgrows native Salesforce email handling
Salesforce teams whose inbound mail carries fields, tables, or vendor formats Email-to-Case and Flow leave as plain text.
Sales & RevOps teams
Capture leads from marketplace, web form, and partner emails that arrive as HTML or change layout, then create a clean Lead or Contact per email in Salesforce instead of parsing the body with Flow.
Service teams on Email-to-Case
Pull order numbers, account IDs, and product details out of the inbound customer mail body, and route the structured data onto Case fields through a CSV import or a webhook.
Operations & logistics
Read shipment tables, tracking numbers, and order IDs from confirmation emails that Email-to-Case files as plain text, and bring clean fields into Salesforce records.
Accounting & finance
Pull invoice numbers, dates, and totals out of the email body and its HTML tables into Excel for a QuickBooks or Xero import, then send the summary record into Salesforce through Flow. When the figure lives inside a PDF, extract the PDF first, then feed the result in.
MailParse vs native Salesforce email handling
Reads the whole body
Email-to-Case drops the entire message onto one field. MailParse pulls the specific values you name out of the body and returns each as its own column.
Handles HTML and tables
Parsing HTML tables in Salesforce means Apex or fragile Flow string functions. MailParse parses HTML emails and table rows into clean columns.
No code to maintain
A native field parse needs an InboundEmailHandler class or a body-slicing Flow that breaks on format change. MailParse reads named fields with no code.
Flexible output
MailParse exports CSV and Excel for spreadsheets and JSON for webhooks, so you import with Data Loader or push records through Flow, Zapier, or Make.
Four ways to parse email into Salesforce, compared
Salesforce gives you three native paths plus the external-parser route, and the right one depends on whether your mail carries HTML tables, fields buried mid-body, or formats that change between senders. Here is an honest side by side, with credit to each method where it wins. For the broader CRM picture, see the email to CRM guide; to weigh parsers against each other, the best email parser guide.
| Decision point | MailParse | Email-to-Case (native) | Apex InboundEmailHandler | Flow string functions |
|---|---|---|---|---|
| What it does | Parses the fields you name from the body and HTML tables, then exports CSV or JSON to load into Salesforce | Turns an inbound message into a Case and files any attachment unread | A custom Apex class reads the message and writes any field you code for | A record-triggered Flow slices the body with text formulas to set fields |
| Setup and skills needed | Name the fields on a form, no code or admin formulas | An admin enables it and adds a routing address, included with your edition | A Salesforce developer writes, tests, and deploys the class | An admin builds and maintains the Flow and its string formulas |
| Parses structured fields from the body | Yes, across senders that format the same data differently | No, the whole body lands on one field unparsed | Yes, but only the patterns you hard-code | Some, tied to fixed text positions in the body |
| Handles attachments | Records the filename for reference; extract a PDF or spreadsheet with a document tool first, then parse the result | Stores the file on the Case but does not read it | Only if you write and maintain a parser for each file type | No, Flow cannot read inside an attachment |
| Parses HTML tables | Yes, repeating table rows come through as clean columns | No, the table is flattened into plain text | Possible only with heavy custom parsing code | Not practical with string functions |
| Holds up when a sender changes layout | Reads the named fields when the layout drifts | Layout does not matter since nothing is parsed | Breaks when the text the code keys on moves | Breaks when a heading is renamed or a line reorders |
| Output and destinations | CSV for Data Loader, or JSON through Flow, Zapier, or Make | A Case record inside Salesforce only | Writes directly to any Salesforce object you code for | Writes to the Salesforce records the Flow targets |
| Best for | HTML tables and varied vendor formats parsed into fields with no code | Logging customer email as Cases with no field extraction needed | Developer teams wanting full native control in one steady format | Admins parsing a simple, consistent plain text body |
Email-to-Case, Apex inbound email services, and Flow are included with your Salesforce edition, so the cost is developer or admin time, not a separate license. Native capabilities and limits change between releases, so confirm current behavior before you build. Capabilities described as of July 2026. No pricing is implied here.
Frequently asked questions
Does Salesforce have an email parser?
Salesforce does not have a point-and-click email parser the way some CRMs do. It can route an inbound message into a Case with Email-to-Case or create a Lead, and the subject, sender, and body land on standard fields. To extract structured values from the body, you write an Apex class with the Messaging.InboundEmailHandler interface or build a Flow. MailParse does that extraction for you and hands Salesforce clean CSV or JSON.
How do I parse an email into Salesforce?
Three native paths exist: Email-to-Case to create a Case, a Flow that slices the body with string functions, or an Apex inbound email service for full control. All of them need a developer or admin and break when a sender changes formatting. The simpler route is to parse the mail in MailParse, name the fields you want, then import the CSV or push JSON into Salesforce through Flow, Zapier, or Make.
Does Email-to-Case read the email body into fields?
No. Email-to-Case lands the subject, sender, and full body on standard Case fields, but it does not split structured values such as an order number or account ID out of the body. MailParse reads the fields you name from the body and HTML tables, then gives you CSV or JSON to load into Salesforce records.
Can Salesforce extract data from the email body?
Only with code or formulas. An Apex InboundEmailHandler class or a Flow with string functions can slice values out of a plain text body, but both are tied to fixed text positions and fail when a vendor reorders a line or sends HTML. MailParse reads the fields you name across varied layouts and HTML tables, so a formatting change does not silently drop a value.
Can MailParse read data inside email attachments?
MailParse parses the email body and HTML tables, and it records the filename of any attachment for reference, but it does not read the data locked inside a PDF, Word, or spreadsheet file. When the value you need lives inside an attachment, extract that file with a document tool first, then feed the result into your Salesforce import.
How do I import parsed email data into Salesforce?
Two paths work. Export the parsed data from MailParse as a CSV and load it with the Data Import Wizard or Data Loader to create or update Leads, Contacts, Cases, or custom records in bulk. Or take the JSON from a MailParse webhook and send it through Flow, Zapier, or Make to create a record per email automatically as mail arrives.
Is the Salesforce email parser free?
There is no separate paid email parser to buy from Salesforce. Email-to-Case, Flow, and Apex inbound email services are included with your edition, but turning the body into structured fields costs developer or admin time and stays fragile. MailParse complements those features by parsing the body and HTML tables into named fields and exporting CSV or JSON you load back into Salesforce.
Parse the email body Salesforce leaves as text, then send it into Salesforce
Connect a mailbox or forward a message and see the fields and HTML table rows Email-to-Case and Flow leave unparsed land in clean CSV or JSON, ready to import or webhook into Salesforce.