Email Channel — Outbound

How Outbound Works

Outbound email is delivered by the built-in send_email action tool. When the agent decides to send a message, the platform:

• Validates that recipient, subject and body are present
• Looks up the recipient’s email address against Contact and Lead records and links the matched record to the email so it appears in activity history
• Appends the running user’s standard Salesforce signature when one is configured, or builds a fallback signature from the user’s name, role and email
• Routes the send through the org-wide email address if one is available
• Sets the related-to record (when supplied) so the email is logged on that record’s activity history
• Optionally links the email to one or more pending reply-tracked Scheduled Actions so a reply from the recipient automatically resumes the conversation
• Saves the email as an Activity

Two delivery modes are available. The agent can send the email now using send_email directly, or it can defer the email by calling schedule_action with a future timestamp or a reply trigger. Both modes use the same underlying send.

Sending Now: the send_email Tool

Assign the built-in send_email tool to any agent that needs to send mail. The agent provides:

Because send_email is an Action tool, an agent in an interactive UI surfaces a confirmation card with the full draft before sending — the user reviews recipient, subject and body and clicks Send. On non-interactive channels (Email Inbound, Flow-driven, messaging integrations) where a confirmation card has nowhere to render, configure the agent for Auto Execute Actions so the send happens immediately. See Action Confirmation for the full flow.

Scheduling for Later: schedule_action

For follow-ups, reminders and reply-triggered messages, the agent uses the built-in schedule_action tool with action_type set to Email. The action stores the email payload on a Scheduled Action record and a scheduled job sends it at the right time.

Scheduling supports three trigger styles:

• Absolute time — send at an ISO-8601 timestamp.
• Relative offset — send N minutes/hours/days from now.
• Reply-triggered — send when (and only if) the recipient replies to a previous outbound email tracked through the same group_key.

See Scheduled Actions for the full execution model and observability.

What the Recipient Receives

The platform composes the outgoing email so it looks and behaves like an email from a real Salesforce user, not a faceless system:

• From — the running user, or an org-wide email address if one is configured (see below).
• Signature — the running user’s configured Salesforce signature if set; otherwise a built one with name, role and email.
• To — the address the agent chose. When that address resolves to a single Contact or Lead, the email is associated with that recipient for activity tracking.
• Activity history — the email is saved as a Salesforce Activity, attached to the recipient and to the related-to record when one was passed.
• Branding — when the sending agent has an active Branding record linked, the email is delivered as branded HTML (logo, colors, header and footer) with the signature above your footer, plus a plain-text part. Without a linked brand it stays plain text, exactly as described here.

Configuring the Org-Wide Address

By default the email is sent from the running user’s address. To present a single brand-friendly From address regardless of who runs the agent, configure an org-wide email address:

With one org-wide address marked “Allow All Profiles”, every outbound email the agent sends will use that From address regardless of which user is running the agent.

Choosing the Sender and Reply Address

An agent’s instructions can name the identity a particular email should be sent from, and where replies to it should go. This is useful when one agent sends on behalf of more than one team — a billing query answered from billing@, a leasing enquiry from leasing@ — without needing a separate agent for each.

These are set through the agent’s instructions rather than on a settings page, which is what lets the agent pick the right identity per email instead of using one fixed sender for everything. Describe in the instructions which identity applies to which kind of message.

What happens when something does not match

The email is never dropped because an address was wrong — an agent going silent over a typo would be worse than an email arriving from the default sender:

• If the requested sending address cannot be matched to a verified org-wide address, the email is still sent using the default sender, and the mismatch is recorded.
• If the reply address is not one that can route a reply back into a conversation, it is applied as asked and recorded — so a broken reply loop can be found rather than silently swallowing replies.

Both are visible afterwards, so a sender that is not behaving as intended can be traced rather than guessed at.

Stamping Your Own Fields on the Email

Every email an agent sends creates an EmailMessage record. If you have added custom fields to that object — an outreach category, a campaign code, a service-level flag — the agent can fill them in as it sends, so the email is classified at the moment it goes out rather than in a clean-up pass afterwards. This is driven by the agent’s instructions, not by a setting: tell the agent which field to set and to what, and it passes them with the send.

Only custom fields (those ending in __c) can be set this way. Standard fields such as the subject, status or sending address are owned by the send itself — letting an agent rewrite them would corrupt the record of what was actually sent. Field names are checked against your org’s schema first, anything unrecognised is skipped rather than guessed at, and a field that cannot be written never costs you the email: the send still succeeds and the agent is told which fields were set and which were skipped. Full input details are in the Built-in Tools Reference.

Recipient Resolution & Activity History

When the agent sends to an email address that matches a unique Contact or Lead in the org, the platform sets that record as the email’s recipient on the underlying EmailMessage — producing a clean activity-history record on the contact and on any related record passed via related_to_id.

If the address matches more than one record or none, the email still sends but does not link to a recipient record. Pair the agent with the built-in soql_query tool so it can look up the right Contact before sending; this dramatically improves activity hygiene.

Reply Tracking with Group Keys

REDA AI supports a clean pattern for “send a follow-up if the recipient hasn’t replied within X days” or “take this action when they reply”. The agent:

The reply-tracking feature requires standard Salesforce email infrastructure (typically Email-to-Case or another configuration that captures replies as EmailMessage records). The platform uses dynamic SOQL so the package compiles cleanly even in orgs that don’t have it enabled.

Tracking, Limits & Governance

• Standard Salesforce email limits apply. Daily mass-email caps, deliverability settings and bounce management are governed by Salesforce, not by REDA AI.
• Field-level security applies to recipient lookup. The Contact/Lead lookup runs in user mode; if the running user can’t see Contacts, the resolution silently fails and the email sends without a linked recipient.
• Audit trail. Every send is captured as an EmailMessage and Activity in the standard Salesforce way, plus on the Conversation and Message records for the agent run.
• Action confirmation. Default behaviour is to surface a confirmation card. Auto-execute is available for non-interactive channels.
• Errors don’t silently disappear. A failed send returns a structured error to the agent with the underlying message so the agent can either retry, ask the user, or report the failure.

Best Practices

Pre-resolve the recipient. Have the agent run a SOQL query for the matching Contact or Lead before composing the email. Activity history is much cleaner when the email links cleanly to a record.

Always set related_to_id when there’s a record context. If the agent is on an Opportunity page or processing a Case, pass that record’s Id as related_to_id so the email shows up on its activity history.

Use group_key when you also schedule follow-ups. Reply tracking and timed follow-ups depend on a shared group_key. The conversation Id is usually a good default.

Configure an org-wide address for production. Sending from the running user’s personal address is fine in sandbox; in production a verified org-wide address keeps the brand consistent and reduces deliverability surprises.

Be deliberate about Auto Execute. A confirmation card is a meaningful safety net on interactive channels. Disable it only on channels where it cannot render — document-intake email, messaging integrations, Flow-driven background runs.

Constrain the sender on autonomous agents. When an agent is sending email without human review, lock the persona prompt to a specific tone and template, and consider a tighter custom outbound tool that constrains what the agent is allowed to write.

Clearer email, record and scheduled actions

Email actions distinguish a Contact or Lead recipient from the related business record, support To/Cc lists, and check the supported recipient opt-out cases. Contact/Lead values supplied as related records are handled as recipients instead of invalid activity links. Record confirmations surface fields that were not applied, rather than silently implying success. Plan steps are reconciled one-to-one; relative scheduled times retain UTC correctly. Disabled agents and disallowed nested actions are checked before confirmed execution. File-link confirmation reuses the supported access-aware path. New Pending or rescheduled time-based actions require a runnable scheduled processor; email-reply tracking and ordinary history/status updates remain valid. Delayed jobs run as their scheduler owner, not by impersonating the requestor. Host guidance reduces duplicate use of another email/calendar connector; it cannot guarantee the host's behaviour.

Frequently Asked Questions

Next Steps

Read Email Reply Handling for the inbound side of reply tracking, or Scheduled Actions for the deferred and reply-triggered execution model.