Email-to-Case turns inbound emails into Case records automatically, preserving sender, subject, body, and attachments. Two flavours:
- On-Demand Email-to-Case — fully cloud-managed. You forward emails from your support address (e.g., support@company.com) to a Salesforce-generated routing address. Salesforce parses and creates the Case. No infrastructure.
- Email-to-Case (relay agent) — for organisations that need emails to stay on-premise initially (compliance, no cloud forwarding allowed). Requires a Java agent installed on a company server that polls a mail folder and pushes cases to Salesforce via API.
Setup (On-Demand):
- Setup -> Email-to-Case -> Enable.
- Enable On-Demand Service.
- Create a Routing Address — pick the email address users send to (support@), specify which case fields are pre-populated (Origin, Owner, Priority defaults), and enable "Insert thread ID in email subject" so reply-tracking works.
- Configure your mail server to forward inbound emails to the Salesforce-generated routing address.
- Test end-to-end with a sample email.
Common configuration:
- Threading — Salesforce inserts a hidden thread ID into the case-update notification email so when the customer replies, Salesforce knows to append to the existing case rather than create a new one. If customers strip the subject, threading breaks.
- Auto-Response Rules to send the customer a "we received your case" acknowledgement.
- Assignment Rules to route incoming cases to the right team based on email content.
- Spam handling — Email-to-Case is a known spam vector; use SPF/DKIM, an upstream mail filter, and case rejection criteria.
- Attachments — supported but inherit the org's attachment size limits. Very large attachments can fail silently.
Limits: 2,500 emails/day on Performance/Unlimited (less for smaller editions), and an attachment size cap.