Email Channel — Inbound

What This Channel Is — And Isn’t

The Inbound Email channel hands each email to the agent mapped to the receiving address. When an email arrives at a configured, routed Email Service address:

• The platform matches the address to an agent and queues an async job — whether or not the email carries attachments
• If attachment processing is enabled, qualifying attachments are filed as ContentVersion records and passed to the agent alongside the body
• If the address has no active routing record, the email is ignored
• The platform never bounces the email and never auto-replies to the sender — if you want a reply, the agent sends one through the outbound channel

The routing setup itself — the Email Service plus an active routing record — is what turns the channel on for an address. There is no separate feature switch to enable inbound routing.

This is a one-way intake channel: the platform doesn’t auto-reply. For the agent to reply by email, see Email Channel — Outbound, and Email Reply Handling for tracking replies to agent-initiated emails.

Architecture

Setting It Up

Step 1 — Decide whether to process attachments

In the REDA AI Admin tab, Email File Processing Enabled controls whether file attachments on inbound emails are processed. It is off by default and is a security control, not a channel switch:

• Leave it off for conversational intake — the agent receives the email body, subject and sender, and any attachments are ignored.
• Turn it on to also file qualifying attachments as ContentVersion records and pass them to the agent for document processing.

Either way, the channel is enabled by the routing setup in Steps 2–3 — a routed email reaches the agent regardless of this setting.

Step 2 — Create the Email Service in Salesforce Setup

Step 3 — Create routing records

Routing records map each inbound address to a specific agent. Manage them from the REDA AI Admin tab › Operations › Email Routing.

1. Open the REDA AI app and select the REDA AI Admin tab.
2. Scroll to the Email Routing card under Operations.
3. Click + Add Routing.
4. Fill in the form and save:

Unmatched inbound addresses produce an Incident Log entry and are silently dropped — no auto-reply is sent. There is no domain or wildcard matching; one routing record per address you want to support.

Editing, deactivating and reactivating

• Edit — pencil icon on the row. Open the form, change any field, save.
• Deactivate — ban icon on an active row. The record stays in the table (greyed out) so you can reactivate it later or repurpose it for a different email.
• Reactivate — check icon on a deactivated row.
• No hard delete — routing entries are deactivated rather than deleted. Inactive entries don’t affect runtime behaviour and remain visible for re-use.

Routing records you create are stored as subscriber-owned configuration and survive package upgrades. New REDA AI versions will not overwrite or remove your routings.

Step 4 — Configure the agent

The routed agent should be set up with this channel in mind:

• Give it a clear persona that knows it’s processing a document, not chatting with the sender.
• Assign the right tools. Most email-intake agents need built-in read tools, plus a domain-specific File Mapping or Apex Class tool that turns the extracted data into Salesforce records.
• Consider enabling Auto Execute Actions — there’s no human in front of a confirmation card on this channel. Either auto-execute, or restrict the toolset so the agent can only write through tools you trust.
• Confirm that all tools you want the agent to use include API in their channel scope, since the email pipeline calls the agent server-side.

What the Agent Sees

For each inbound email, the agent receives a fresh conversation containing:

• The sender’s address (as text in the message)
• The email subject (as text in the message)
• The body of the email, truncated to a sensible length — the plain-text part, or the stripped HTML when the email is HTML-only
• When attachment processing is enabled, the list of qualifying attachments, available through the same Document Processing pipeline as any other channel

The platform does not currently match the sender to a Contact or Lead automatically, and it does not thread emails by Message-Id. Each inbound email starts a new conversation. If you need sender resolution or threading, build it into a custom Apex tool the agent can call — for example, a tool that searches Contacts by email address and returns the match.

Attachment Filtering

See Platform Settings for the configurable values that govern these filters and Document Processing for what happens to a file once it reaches the agent.

Asynchronous Execution

The Email Service handler always returns success immediately. Real processing happens in a Queueable job that runs in the background. Two implications matter:

• The sender will not see an inline failure. If the email is malformed, the address is unrouted, or the agent errors, the platform records an incident but does not bounce or auto-reply. Plan for that — if you need to confirm receipt, configure the agent to send a confirmation email through the outbound channel.
• Senders can blast volume. Salesforce’s Email Service has its own daily limits; on top of that, REDA AI’s credit and concurrency limits apply per agent run. For high-volume senders, watch the Incident Log for failures and consider a dedicated Queueable concurrency review.

Observability

• Conversation records — one per inbound email that produced an agent run. Filter by automatedSource = the email pipeline label to find them.
• Incident Log — capture for failed or unroutable email: an email that matched no routing record but still reached processing, an agent error, an async-request timeout. See AI Incident Logs.
• Conversation Debugger — for any individual run, the Debugger shows the assembled prompt, the file blocks the agent saw, and every tool call it made.

Security & Governance

• Salesforce-managed addresses. Inbound traffic terminates at Salesforce’s Email Service before reaching REDA AI. SPF/DKIM and standard email security apply at that boundary.
• Files stay in your org. Attachments become ContentVersion records subject to your standard sharing and retention rules. Nothing is copied to an external store.
• The agent runs as a real Salesforce user. The Email Service handler runs as the user configured on the service; that user’s permissions govern what the agent can read and write.
• Attachment processing is off by default. The Email File Processing Enabled security control makes handling inbound files an explicit decision — until you turn it on, attachments are ignored even on a routed address. (The channel itself comes online only when you create an Email Service and an active routing record, so nothing processes inbound email silently after install.)

Best Practices

Use one address per intake type. Separate addresses for invoices, contracts and onboarding docs let you route each to a focused agent with a tight toolset, instead of one general agent that has to figure out the email’s purpose.

Confirm receipt by sending a reply. Because the channel never auto-replies, a polished setup includes an outbound email tool the agent calls at the end of its run to acknowledge processing — success or failure.

Keep agents file-aware. The agent’s prompt should mention that it is reading documents that arrived by email. That changes the response style: shorter, structured, focused on the action it took rather than chatting.

Watch the Incident Log on day one. Most setup mistakes — missing routing records, misspelt agent Ids, disabled agents — surface there. Triage the log for the first week of operation.

Plan for sender resolution if you need it. If the agent needs to know which Contact or Lead sent the email, ship a custom tool that does the lookup; the platform doesn’t do this automatically.

Frequently Asked Questions

Next Steps

Set up Email Channel — Outbound so the agent can reply, or read Email Reply Handling to learn how the platform tracks replies to agent-initiated emails.