Email Reply Handling
What This Page Covers
Email Reply Handling is the inbound side of agent-initiated email. It pairs with two other features:
- Email Channel — Outbound — how the agent sends the original email and tags it for reply tracking with a
group_key. - Scheduled Actions — how follow-up actions are stored and executed, including reply-triggered ones.
It is not the same as Email Channel — Inbound, which is for unsolicited document intake at a Salesforce-managed Email Service address.
How Reply Detection Works
REDA AI exposes an Apex invocable, Process Inbound Emails, which inspects newly-arrived EmailMessage records and decides whether they are replies to agent-initiated emails. Customers wire it up with a record-triggered Flow on EmailMessage.
-
Agent sends email
The agent calls
send_emailwith agroup_key. The platform stamps the resulting EmailMessage Id and subject onto any pending reply-tracked Scheduled Action sharing that group key. See Email Channel — Outbound. -
Inbound replies captured
Inbound replies arrive through whatever Salesforce email infrastructure is configured — typically Email-to-Case, but the feature is infrastructure-agnostic. Each reply produces an
EmailMessagerecord withIncoming = true. -
Flow fires
A customer-built record-triggered Flow on
EmailMessage(after insert, filtered to inbound) calls the Process Inbound Emails invocable with the new EmailMessage Ids. -
Fast-exit check
The handler does a single SOQL query to see whether any pending reply-tracked Scheduled Actions exist at all. If none, it returns immediately. Most orgs spend almost no Apex time here on average.
-
Async matching
If pending actions exist, the handler enqueues a Queueable that runs the actual matching against the inbound EmailMessage records.
-
Match strategy
The Queueable uses two matchers: a robust parent-thread match (the inbound reply’s parent EmailMessage equals the tracked outbound EmailMessage Id) and a subject-line fallback (normalised “Re:/Fwd:” prefixes stripped) when the parent isn’t set.
-
Action activates
For each matched reply, the corresponding Scheduled Action is moved out of pending state. If the action is configured to process via AI, the reply text is routed into a new agent turn; otherwise the action’s payload (e.g. a templated outbound email or record update) is executed directly.
Setting It Up
Step 0 — Turn Email Reply Tracking on
Email Reply Tracking ships disabled, and nothing here works until it is on. It is a Platform Setting (REDA AI Administration › Configuration › System & Notifications). The handler checks it first on every inbound email and returns immediately when it is off — so a perfectly built Flow, correct entry conditions and well-configured agents will all sit there doing nothing, with no error and nothing in the logs to say why.
Reply tracking also requires Enhanced Email to be enabled in the org, since that is
what makes Salesforce create the EmailMessage records the whole mechanism reads.
Step 1 — Confirm replies become EmailMessage records
Reply Handling depends on inbound replies landing in Salesforce as EmailMessage records. Most orgs already have this through Email-to-Case. Other valid setups include Lightning Email Relay, Email-to-Salesforce with appropriate routing, or a custom Email Service that creates EmailMessage records itself.
The platform uses dynamic SOQL to read EmailMessage, so the package compiles even in orgs where the object isn’t available. Reply Handling simply does nothing in those orgs.
Step 2 — Build the record-triggered Flow
-
Object: EmailMessage
Configure the Flow as record-triggered on
EmailMessage, fired after a record is created. -
Entry condition:
Incoming = TRUEFilter to inbound emails only. Outbound EmailMessages don’t need handling here.
-
Optional: tighter filtering
If you want to scope the Flow to specific email use-cases — only those tied to particular cases, or excluding certain mailboxes — add additional entry conditions. The invocable is safe to call with any inbound EmailMessage, so over-firing only costs a little Apex.
-
Add the Apex Action
Pass the triggering record’s Id as the input collection. The action accepts a list of EmailMessage Ids; the Flow only has one record per fire, but the invocable handles either form.
-
Activate
Save and activate the Flow. From this point, every inbound reply is offered to the platform for matching.
Step 3 — Configure agents to use reply-tracked scheduled actions
The Flow only does its job if there are pending reply-tracked Scheduled Actions to match against. Make sure the agent that sends outbound emails is also calling schedule_action with reply triggers when appropriate, and that both calls share the same group_key. See Scheduled Actions for the action contract.
Step 4 — Point replies at an address that lands here
All of the above only runs once a reply has actually arrived in Salesforce. Where a reply goes is decided by the address the recipient’s mail client answers to — so an agent can set a reply address on the emails it sends, and that address is what closes the loop. Point it at the mailbox wired to the routing in Step 1 and the reply comes back into the conversation; point it somewhere unmonitored and the reply is never seen here, however well the Flow is configured.
The reply address is set through the sending agent’s instructions — see Choosing the Sender and Reply Address. If an agent sets a reply address that cannot route a reply back, the email still sends and the mismatch is recorded, so a loop that is quietly going nowhere can be found.
Two Matching Strategies
The Queueable uses two strategies, in order:
| Strategy | How it matches | Reliability |
|---|---|---|
| Parent-thread match | The inbound reply’s ParentId (or the outbound message it threads to) equals the tracked outbound EmailMessage Id stamped on the Scheduled Action. |
Strongest. Used whenever Salesforce’s thread linking has populated the parent reference. |
| Subject fallback | The inbound reply’s normalised subject (with Re:, Fwd: and similar prefixes stripped) equals the normalised subject stored on the Scheduled Action. | Useful when thread linking didn’t happen, or when the reply landed through an infrastructure that doesn’t preserve parent references. |
Subject matching is intentionally a fallback. If a single subject is reused across multiple Scheduled Actions for the same recipient, expect the parent-thread match to handle the disambiguation; otherwise design the agent to use unique subjects.
What Happens After a Match
The Scheduled Action’s Process Via AI flag drives what happens next:
- Process Via AI = true — the inbound reply text is routed into a new turn of the original agent. The agent sees the reply as if the user had typed it, and produces the next response (which may, in turn, schedule another reply-tracked email).
- Process Via AI = false — the Scheduled Action’s pre-defined payload is executed directly. This is the right pattern for fixed playbooks: a templated thank-you email, a record-status update, an internal notification.
Either way, the original Scheduled Action is moved out of pending state so it can’t fire again. If the recipient sends multiple replies, only the first one matched activates the action.
Conditions are checked here too
If the matched Scheduled Action carries a condition, it is checked before anything runs — exactly as it would be for an action firing on a schedule. A reply arriving does not by itself mean the action should still go ahead: the record it relates to may have moved on in the meantime. If the condition is not met, the action is Skipped and the reason is recorded on it. See Conditional Execution for how conditions are built.
Observability
- Scheduled Action records — the lifecycle (Pending → Reply Received → Executed) is visible on the Scheduled Action record. The tracked outbound EmailMessage Id and subject are stored alongside the trigger configuration.
- Conversation records — when Process Via AI is on, the agent turn triggered by the reply is appended to the original conversation, keeping the multi-turn history coherent.
- Incident Log — if the inbound EmailMessage can’t be processed (governor errors, Apex exceptions, malformed data), an Incident Log record is created. The Flow itself isn’t responsible for retries; standard Salesforce error handling applies.
Security & Governance
- The Flow runs as the user who created the EmailMessage. For Email-to-Case that’s the Automated Process user; for other configurations it depends on your setup. The user must have access to Scheduled Action records for matching to succeed.
- Replies aren’t blindly trusted. Only inbound EmailMessages whose subject or thread matches a pending reply-tracked Scheduled Action ever activate anything. Spam, bounces and unrelated replies have no effect.
- Subject collisions are bounded. Each Scheduled Action stores its tracked subject with the original casing; the matcher normalises only the reply prefixes, not the body of the subject, so two unrelated agents with identical subjects in their templates is the only practical risk.
- No reply, no action. Reply-tracked actions are gated on actually receiving a reply — they don’t fire on a timer. Pair them with a time-based Scheduled Action if you also want a follow-up if the recipient never replies.
Best Practices
Always pair send_email and reply-tracked schedule_action in the same group. The platform links the outbound email to the action only if both calls share a group_key.
Make subjects distinctive. Subject fallback matching is the failsafe when thread linking doesn’t happen. The more distinctive the subject, the less ambiguity downstream.
Use Process Via AI sparingly. Routing replies into a fresh agent turn is powerful but uses credits and prompt-caching capacity. For simple acknowledgements or stage updates, a templated payload is cheaper and more predictable.
Combine reply triggers with timeouts. Schedule a reply-tracked follow-up and a time-based fallback in the same group. If the reply lands first, the platform fires the reply-tracked one; otherwise the timer fires the fallback.
Keep the Flow narrow. Add an entry condition that filters the Flow to Incoming = TRUE at minimum, and consider stricter filters for high-volume orgs. Apex per inbound email is small but not free.
Frequently Asked Questions
It requires some Salesforce configuration that lands inbound replies as EmailMessage records. Email-to-Case is the most common, but any configuration that produces EmailMessage records on inbound — including custom Email Service handlers and Lightning Email Relay setups — works.
The platform uses dynamic SOQL, so it compiles fine in orgs without EmailMessage. Reply-tracking simply doesn’t fire there — agents can still send email and schedule time-based follow-ups, just not reply-triggered ones.
The matching logic involves async work, dynamic SOQL, normalised subject comparison and conditional handoff to an agent run. Wrapping it in a single invocable keeps the Flow trivial and lets the platform evolve the matching internals without breaking customer Flows.
The first reply that matches activates the Scheduled Action and moves it out of pending state. Later replies don’t re-fire it. To accept multiple turns, the agent should schedule a fresh reply-tracked action each time it sends a new outbound email.
The matcher falls back to subject comparison. The inbound subject is normalised (Re:/Fwd: prefixes stripped) and compared against the tracked subject stored on the Scheduled Action. If both match an active pending action, that action activates.
Yes — that’s exactly what Process Via AI does. The reply body is passed to the agent as the next user message in the conversation that started with the original outbound email.
The Flow fires harmlessly. The handler’s fast-exit check finds no pending reply-tracked actions and returns immediately, costing only a single SOQL query per inbound email.
Next Steps
Read Scheduled Actions for the action lifecycle, including reply triggers and time-based fallbacks, or revisit Email Channel — Outbound for how to wire the outbound side with group_key.