Email Services: Setup & Enablement

Q: Which failure actions should I set on the email service?

Set the over-limit action to Requeue, and set the deactivated-address, deactivated-service, and authentication/authorization-failure actions deliberately — Bounce is recommended so senders are told, rather than Discard, which silently drops mail.

All Users 10 min read Updated July 2026

This is the administrator's runbook for switching on REDA Email Services — the inbound capability that auto-syncs customer email onto records and turns email into Inquiries and Service Requests. Enablement is a short, ordered sequence: assign a permission set, activate the inbound email service and obtain the address Salesforce generates for it, point your mail flow at that address, and set a handful of configuration records and page-layout fields. There's no single org-wide switch to flip — activating the email service and routing mail to it is the enablement. Work through the steps below in order and you'll have all three capabilities live.

OEM edition only. Email Services ships in the OEM edition of REDA, built for Platform-license orgs. If your org is the Sales-Cloud variant, this feature isn't present and there's nothing to enable. Confirm your edition before you begin.

What ships vs. what you configure. Installing the package brings in the objects, the permission set, the Unmatched Email tab and record page, the intake configuration, and the handler — but not a working email address, and not your real domains. The email address is generated per org after install, and the internal-domains record ships as a placeholder you must replace. Those two are the steps most often missed.

Using REDA Sales Cloud edition? This article shows the Platform edition, where prospects are Inquiry records (the standard Salesforce Lead in Sales Cloud) and maintenance and service requests are Service Request records (the standard Case). Everything else — the fields, the steps and the behaviour — is the same unless noted. See REDA editions.

Before you start

The REDA OEM package is installed in your org (its objects, permission set, tab, record page, and configuration records are present).
You have Setup access to create Email Services, edit custom metadata, and edit page layouts.
You've chosen a context user — a licensed Salesforce user the intake will run as. This user needs the permission set (Step 2) and should be a stable, non-personal account.
Your mail administrator (Google Workspace or Microsoft 365) is available to set up a copy or redirect rule (Step 4).

Enablement, step by step

1. Confirm the install. In Setup, verify the package is installed and that the Unmatched Email tab, its object, and the intake configuration are present. If you're sending email from Salesforce as well, ensure Enhanced Email is enabled; it isn't required for inbound intake to work but keeps native Email Message behavior consistent across the org.

2. Assign the REDA_Email_Integration permission set. Assign REDA - Email Integration to the context user and to every triage admin or agent who will work the queue. See Who gets the permission set below for guidance on personas.

3. Activate the inbound email service and get its address. In Setup → Email Services, open the REDA InboundEmail Handler email service (its processing logic is provided by the package — there's nothing to build). Set the context user, mark the service Active, and confirm the accept-attachments and failure settings in the email-service settings below. Then add an email address under the service and copy the generated …@…apex.salesforce.com address — this address is provisioned per org and is not shipped in the package.

4. Route your mail to that address. In Google Workspace or Microsoft 365, set up a server-side copy (Bcc / "also deliver to") or a redirect of each monitored mailbox to the Salesforce address from Step 3. Do not use a personal Forward — a forward rewrites the sender and breaks matching. See Routing your mail.

5. Set your internal domains. Replace the placeholder in the internal-domains configuration record with your organization's real email domains, so REDA can tell staff email from customer email. See the internal-domains record. This is a required step, not optional.

6. Choose the failure actions deliberately. On the email service, set the over-limit and address/service-failure actions on purpose rather than accepting whatever a fresh install shows. See the settings table for the recommended choices.

7. Set the Region and Inquiry contact fields. Add Omni Inbox Contact to the Region page layout, and Omni Inbox Contact (Override) to the Inquiry page layout. These decide who an Inquiry-email activity is logged against. See Page-layout fields.

8. Add the intake fields to layouts. Make sure the Inquiry and Service Request page layouts show the fields intake populates, so triage staff can see what came in from email. See Page-layout fields.

9. Confirm the "Email" Inquiry source. Check that the Inquiry Source picklist includes its Email value, so email-created Inquiries are attributed correctly in reporting.

10. Activate the Unmatched Email record page. Ensure the Unmatched Email Lightning record page is set as the org default so the Match-to-Record panel appears when a triage admin opens a held email. See Triage: the Unmatched Email Queue.

11. Configure your intake addresses. For Email-to-Inquiry and Email-to-Service-Request, replace the shipped example rows with your real intake addresses — one active configuration row per address. See Intake configuration.

12. Test with a real message. Send a test email to a monitored mailbox and to each intake address, then confirm the activity appears on the record (or a new Inquiry / Service Request is created), and that anything unmatched lands in the queue.

Who gets the permission set

Access to Email Services is granted entirely through the REDA - Email Integration permission set (API name REDA_Email_Integration). It grants create/read/edit/delete and tab visibility on the Unmatched Email object, edit access to the two contact-routing fields, and the underlying processing components. Two personas need it:

Setup, Email Services, listing the REDA InboundEmail Handler with its Active checkbox ticked and its Apex class REDA_EmailInboundHandler, alongside a second Vendor Invoice Handler service, with the Last Modified By column blurred for publication.

Setup → Email Services showing the REDA InboundEmail Handler service marked Active, with the Apex class that handles it. Open the service to see its generated inbound address — that address is unique to your org, so it is not shown here.

Persona	Why they need it
Context user (the account the intake runs as)	The inbound processing runs as this user; it must be able to create Unmatched Email records and read the routing fields. Assign the permission set here first.
Triage admins / agents	Anyone who works the Unmatched Email queue — opening held emails, matching them to records, or ignoring them — needs the tab, the records, and the Match-to-Record panel.

End users don't need it. People who simply read auto-synced emails on a Contact or Inquiry don't need this permission set — they see the logged Email Message and activity through their normal record access. The permission set is specifically for the intake user and the triage team.

The inbound email-service settings

When you open the REDA InboundEmail Handler email service in Step 3, set it up as follows. The processing logic ships with the package; you're confirming the runtime settings and adding the address.

Setting	Set it to	Why
Processing handler	Provided by the package — not something you configure	This is what reads each message and files or creates records. It ships with the install; there's nothing to build or select.
Active	Checked	The service must be active to receive mail.
Accept Attachments	All	So customer attachments are captured and saved to the record's Files. Anything less drops attachments.
Over-limit action	Requeue	If daily processing limits are hit, mail is requeued rather than lost. Never set this to Discard.
Advanced Email Security	Unchecked (authentication not required)	Leave off unless you have a specific reason; requiring authentication can reject legitimate copied mail.
Deactivated-address / deactivated-service / authentication-failure / authorization-failure actions	Choose deliberately — Bounce is the recommended, sender-visible choice	A fresh setup may show these as Discard, which silently drops mail. The package does not enforce a choice here, so set each one on purpose. Bounce tells the sender something went wrong; Discard hides it.

Don't leave the failure actions on their as-installed value. These edge-case actions aren't guaranteed by the package, and an as-installed value of Discard will silently drop mail on a deactivated address or an authentication hiccup. Set each of them — and the over-limit action — deliberately at setup time.

Routing your mail to Salesforce

REDA doesn't log into your mail provider; instead, your mail system delivers a copy of inbound mail to the Salesforce email-service address. The how matters:

Method	Use it?	Notes
Server-side copy (Bcc / "also deliver to")	Recommended	Delivers a copy to Salesforce while the original still reaches your mailbox. Preserves the real sender, which matching depends on.
Server-side redirect	Acceptable	Redirects the message to Salesforce, preserving the original sender. Use where a copy isn't available.
Personal / client Forward	Do not use	A forward rewrites the From address to the forwarder, so every message looks like it came from staff — matching fails and everything lands in the Unmatched queue.

Set the copy or redirect rule up in Google Workspace routing or a Microsoft 365 mail-flow rule, targeting the address you copied in Step 3. Your mail administrator owns this piece; REDA only receives what your mail system sends it.

The internal-domains record

REDA needs to know which email domains are yours, so it can tell a customer's message from internal staff mail and route accordingly. That list lives in a single internal-domains configuration record.

The internal-domains record ships as a placeholder — you must replace it. Out of the box, this record holds a placeholder value, not your real domains. Set it to your organization's actual email domain(s) before going live. If you skip this, REDA can't reliably distinguish internal mail from customer mail. On a fresh install this may still show the shipped placeholder, so verify and replace it as part of enablement.

Page-layout fields

A few fields need to be visible on the right layouts so both routing and triage work. Add these:

Object / layout	Field	What it does
Region	Omni Inbox Contact	The regional default Contact that Inquiry-email activities are logged against when the sender isn't a known Contact.
Inquiry	Omni Inbox Contact (Override)	A per-Inquiry override of the regional default, for when a specific Inquiry should route its email activity to a different Contact.
Inquiry	Inquiry Source (confirm present), Email	So email-created Inquiries are attributed to the Email source and the sender's address is visible.
Service Request	Subject, Description, Contact	The fields intake populates from an email — its subject, its body, and the linked sender Contact when known.

How the contact routing resolves. For an Inquiry-email activity where the sender isn't a matched Contact, REDA picks the "who" in order: the Inquiry's Omni Inbox Contact (Override) if set, otherwise the Region's Omni Inbox Contact, otherwise none. Setting at least the Region default keeps these activities from being left without a contact.

Intake configuration (Email-to-Inquiry / -to-Service-Request)

Auto-Sync needs no per-address configuration — activating the service and routing mail is enough. The two intake capabilities do: each intake address is defined by one configuration record that says which address it is and whether it creates an Inquiry or a Service Request. The package ships two example rows to show the shape:

Example row	Intake type	Meaning
REDA Example - Leasing	Inquiry	Mail to the leasing intake address creates a new Inquiry.
REDA Example - Support	Service Request	Mail to the support intake address creates a new Service Request.

Replace these examples with your real intake addresses — one active configuration row per address, each set to the correct intake type. Each row can also carry a record type and default field values for the records it creates. The behavior of each capability is covered in Email-to-Inquiry and Email-to-Service-Request.

The example rows point at reda.example. Those aren't real addresses — they're there to illustrate the format. Nothing routes to them until you replace them with your own intake addresses.

The configuration rows are a Custom Metadata Type, Email Service Config, so they live in org setup rather than in a REDA tab. Each row carries:

Field	What to put in it
Email Service Address	The intake address itself — the one your mail flow routes to.
Intake Type	Inquiry or Service Request: what mail to this address creates.
Record Type Developer Name	Optional. The record type to give the records it creates.
Default Field Values (JSON)	Optional. Field values to stamp on every record created from this address.
Active	Clear this to stop an address without deleting its row.

Verifying it works

Once the steps are done, confirm each capability end to end:

Auto-Sync. From an external address that matches a known Contact, email a monitored mailbox. Confirm the message appears as an Email Message and a logged activity on that Contact, with any attachment in Files.

Email-to-Inquiry. From an address with no existing record, email your leasing intake address. Confirm a new Inquiry is created with the sender's name, email, and the message logged, and Inquiry Source = Email.

Email-to-Service-Request. Email your support intake address. Confirm a new Service Request is created with the email's subject and description, linked to the sender's Contact if one exists.

Unmatched queue. From an unknown address, email a monitored mailbox in a way that matches nothing. Confirm it lands in the Unmatched Email queue with its content intact, ready for triage.

Where to go next

REDA Email Services: Overview — the big picture and how the three capabilities relate.
Email Auto-Sync — the matching order and reply threading in detail.
Email-to-Inquiry — intake-to-Inquiry behavior and dedupe.
Email-to-Service-Request — intake-to-Service-Request behavior.
Triage: the Unmatched Email Queue — working held messages.
Email Services: Troubleshooting — when mail doesn't arrive or lands unmatched.

Frequently asked questions

Salesforce generates it when you add an email address under the service after install — it's provisioned per org and isn't shipped in the package. Activate the service, add an address, and copy the generated …apex.salesforce.com address it gives you.

No. Activating the inbound email service and routing your mail to its address is the enablement — there's no separate "sync" toggle to find.

Use a server-side copy (Bcc / also-deliver-to) or a redirect in Google Workspace or Microsoft 365 — not a personal Forward. A forward rewrites the sender, which breaks matching and sends everything to the Unmatched queue.

It ships as a placeholder. Until you set it to your organization's real email domains, REDA can't reliably tell internal staff mail from customer mail, so replacing it is required.

Set the over-limit action to Requeue, and set the deactivated-address, deactivated-service, and authentication/authorization-failure actions deliberately — Bounce is recommended so senders are told, rather than Discard, which silently drops mail.

Was this article helpful?