Salesforce Email-To-Case Implementation

Provide the Following informations:

• Routing Name:
o The name for the routing address—for example, Gold Support or Standard Support. This
name appears in the From field when an agent emails a customer from this email
address.
• Email Address:
o The inbound email address for this Email-to-Case routing address. Emails sent to this
address create cases using the specified settings. The email address must be unique.

Step to Follow
1. The Partner sends a verification email to the email address provided from Salesforce
o Click on the link and allow Salesforce Verification.
2. The Partner shares the mail service address generated in Salesforce. This address is the address
to forward to.

We recommend that you avoid user-configured rules. When users apply redirect or forward rules in
Outlook settings, those rules can alter email headers and impact threading. Some companies can also
restrict users from forwarding to external domains.

• Go to the Exchange Admin Center and create a contact. For the contact’s email address, copy in
the email service address generated in Salesforce.
• Configure forwarding using these options.

Full Inbox Forwarding

(Recommended) This option preserves email headers and can be configured to keep a copy of
incoming emails in the user inbox. In the Exchange Admin Center, select the support mailbox
under Recipients and enable forwarding. Specify the contact’s email service address generated
by Salesforce as the address to forward to.

Mail Flow Rules

(Recommended) When applied by the Exchange admin in the Exchange Admin Center, a redirect
rule preserves headers during forwarding. Have your Exchange admin create a rule that’s
applied when an email recipient includes your support address, such as
support@mycompany.com. Define the rule to redirect the email to your contact’s address, which
is the email service address generated by Salesforce.
Because user-applied rules cause header changes that break threading, we don’t recommend
that users create rules in Outlook settings. If a user configures a forwarding rule in Outlook
settings, Email-to-Case can't identify the sender because the mail system strips out the original
sender address.
 Distribution Lists
If your support address doesn’t map to an actual user, a distribution list is a good method to
forward emails to Email-to-Case. In the Exchange Admin Center, create a distribution group and
add the email contact that you created as a member.

To allow Email-to-Case to thread emails to cases correctly, follow these general guidelines.

1. Configure one routing address to use in forwarding. When customers address emails to multiple
service addresses, emails don’t thread to cases as expected.
2. Avoid defining aliases that map to the same Email-to-Case service address. For example, some
companies define aliases specific to a country, such as support-
us@mycompany.com and support-uk@mycompany.com, that point to the same support
address, support@mycompany.com. If a customer sends an email
to support@mycompany.com and the support-us@mycompany.com alias, the email system
forwards multiple copies of the same email to Salesforce. As a result, Email-to-Case creates
multiple cases and emails aren’t threaded properly.
3. Avoid email rules that add disclaimers or tags before or after the email subject, such
an [External] tag on emails that originate outside of the company. Changing the subject can
break threading on some email clients. If your customer tries to reset the email subject, that
change can also reset the email headers used in threading.
Lightning Sync Configuration Guide -
SalesForce Exchange/Office 365
System Requirements
 Accept incoming Exchange Web Services (EWS) calls from Salesforce
Your internal company policies around Exchange determine what is required in your setup to
ensure Exchange can accept incoming EWS calls from Salesforce. Steps can include:

4. Enabling an EWS endpoint (a common practice with on-premises servers)

5. Using AutoDiscover (optional)
6. If there’s a firewall, allowing incoming EWS calls to originate from Salesforce IP addresses and
domains (allowlists). Valid calls contain json web tokens (JWT)

Review the following for more information.

• External Link: Start using web services in Exchange

• Knowledge Article: Salesforce IP Addresses & Domains to Allow
• External Link: Autodiscover service in Exchange Server
• External Link: Inside the Exchange Identity token

Accept incoming authentication calls to the Exchange Metadata URL from Salesforce
The web tokens contain a MetaData URL. If you use Autodiscover to accept EWS call, the
MetaData URL could be same as the Autodiscover URL.

TIP To check the Exchange server connection and confirm that it’s configured properly to communicate,
use the Salesforce Debug Tool. If you see 500 internal error responses, check Outbound Messaging SSL
CA Certificates to ensure the certificate is valid.

NOTE A service account isn’t required for the Outlook integration. If you’re using Lightning Sync to sync
calendar events and contacts, you could require a service account depending on your configuration.

Use a Service Account to Connect an Exchange Server and Einstein Activity Capture

1. Make sure that your Exchange server is visible to Salesforce by allowing the necessary network
access.
2. Create an Exchange user with a mailbox that acts as the service account.
3. Grant the impersonation role to a service account.
4. Decide which users the service account has access to.
5. Enable Exchange Web Services (EWS) on an SSL connection.