Salesforce Email-to-Case Parsing: 4 Ways to Fill Case Fields

There are four ways to get values out of an Email-to-Case message and into Salesforce case fields, and standard Email-to-Case itself is not one of them. Out of the box, Email-to-Case puts the subject in Subject, the body in Description, and matches the sender to a contact. It fills nothing else from the message. To populate custom fields such as an order number, account ID or product code, you either build a record-triggered Flow, write Apex, license an AppExchange app, or parse the support mailbox before the data reaches Salesforce.

The right choice depends on how templated your inbound mail is and who is going to maintain the logic in a year. A queue of customers describing problems in their own words does not need parsing at all. A queue of partner portals, order systems and monitoring tools that send the same layout every time is leaving its most useful data in a text box nobody can report on.

The four options, compared

Every column below solves the same problem: an email arrives at your support address and a case should exist with its fields already filled. Two of the four are native to Salesforce and cost nothing extra, and for a narrow job they are the right answer.

What does Email-to-Case fill in on its own?

Email-to-Case fills Subject, Description, the contact and account when the sender's address matches an existing contact, and the web email field with the sender's address. Each routing address can also stamp defaults on every case it creates: Case Origin, Priority, Record Type and the owning user or queue. Attachments are kept against the email message. Nothing inside the body is read for values.

Those routing defaults are more useful than they look. If a vendor sends from a dedicated address, you can give that address its own routing entry and every case it creates arrives with the right record type and queue. That solves "which bucket does this go in" without any parsing. What it cannot solve is "what order number is this about", because that answer only exists in the text.

How do you parse the email body into case fields with Flow?

Build a record-triggered Flow on the EmailMessage object that runs when an incoming message is created with a parent case. Use a formula resource with FIND to locate a label such as "Order #:" in the TextBody, MID to take the characters after it, and TRIM to clean the result. An Update Records element then writes that value to the parent case.

For one value from one sender, this is a perfectly good build and it costs nothing. The trouble starts at the third or fourth field. Each value needs its own FIND and MID pair, each pair assumes the label and the line break sit exactly where they did in the sample, and HTML mail arrives in TextBody with its tables already collapsed into runs of text. When a partner renames "Order #" to "Order Number", the formula quietly returns an empty string. Nobody gets an error, and the gap shows up weeks later in a dashboard.

When is Apex the right answer?

Apex is the right answer when you have developer capacity, the parsing logic is genuinely complex, and your security team wants every step to run inside the org. You can implement Messaging.InboundEmailHandler behind an Email Service, or put a trigger on EmailMessage that parses the body after Email-to-Case creates the case. Regex handles messy text far better than formulas do.

The cost is ownership. Every change to a sender's template is a code change, which means a sandbox, test coverage and a deployment. Teams that run this well usually have a developer who treats the parser as a product. Teams that do not end up with a class nobody wants to touch, parsing four senders correctly and failing on the fifth.

Can Einstein fill case fields from the email?

Partly. Einstein Case Classification learns from your recently closed cases and recommends or automatically sets picklist and checkbox fields such as Case Reason, Type or Priority. It predicts a category. It does not read an order number, a serial number, an amount or a date out of the body and copy it into a text field. It needs a Service Cloud Einstein license and enough history to train on.

That makes it a good partner to parsing rather than a replacement. Classification decides which queue a message belongs in. Extraction captures the specific values an agent would otherwise retype. Most queues that feel slow need the second far more than the first.

How do you fill Salesforce case fields without Apex or an AppExchange app?

Parse the support mailbox outside Salesforce and send Salesforce structured data. Connect the mailbox your Email-to-Case address forwards from over IMAP, name the fields your agents actually filter on, and each message comes back as a record with one value per field. Then either post it as JSON through the REST API, Zapier or Make, or load a CSV through the Data Import Wizard.

This is the route MailParse is built for, and it is worth being clear about the trade. You add a tool outside the org, and the case is created or updated through the API rather than by Email-to-Case alone. In return, nobody maintains formulas or code, HTML tables such as order lines keep their rows, and the months of mail already sitting in the inbox can be parsed too, which no trigger-based option does. The email parser API documents the JSON shape, and connecting any mailbox over IMAP covers setup for Microsoft 365, Google Workspace and other hosts.

Many teams keep Email-to-Case exactly as it is for threading and the case feed, and use the parsed record to update the case it created, matched on the thread or a reference number. Agents see the same case they always did, with the fields filled in. Once those fields exist, assignment gets easier too, because a rule can route on customer tier or product line instead of guessing from the subject. If routing across people and queues is the part still eating your team's time, dedicated ticket assignment software can take over that decision once the data it needs is on the record.

Which option should a Service Cloud team pick?

Sort your inbound mail into two piles before choosing anything.

The first pile is people writing to you. Customers describe a billing problem in a paragraph, attach a screenshot and sign off. There is nothing reliable to extract, and Email-to-Case with good routing addresses and, if you have it, Einstein classification is the correct setup. Do not parse this pile.

The second pile is systems writing to you. Order portals, distributor notifications, warranty claim forms, monitoring alerts and marketplace messages follow the same template every time and carry exactly the values your reports need. This is the pile where Description is the wrong destination. If it is one sender and one field, build the Flow this afternoon. If it is five senders, a table of line items, or a backlog you want cleaned, parse the mailbox.

What does setup look like end to end?

Connect the mailbox that already receives the support mail, so senders change nothing. List the case fields you want filled, matching Salesforce API names one for one: order number, account number, product, serial number, requested date. Run your three worst emails through first, the forwarded chain, the one with a nested table and the vendor who writes the total inside a sentence, and adjust the field descriptions until all three come out clean. Only then wire delivery: JSON to the API for real time, or a CSV through the Data Import Wizard for a one-off backfill.

If the same mailbox also feeds another system, the pattern carries over. The ServiceNow inbound email action parser covers it on the ITSM side, and the Jira ticket from email page covers engineering queues.

The short answer

Leave human-written mail on standard Email-to-Case. Use a Flow when one sender sends one or two values in a fixed format. Use Apex when you have a developer who will own it. Parse the mailbox first when several senders, HTML tables or an existing backlog need to become filterable case fields. To see what your own support mail yields, drop in a saved message or connect the mailbox with the Salesforce email parser.