Email Alerts and Outbound Messages

Why This Topic Matters

Email Alerts and Outbound Messages sit at the heart of the Advanced Process Automation section of the Salesforce Advanced Administrator exam. They are two of the four classic automation actions (alongside Field Updates and Tasks) that have been reusable across Workflow Rules, Approval Processes, and now Flow. The exam tests whether you can choose the right action for a business scenario, understand its limits, and troubleshoot it when it fails. Because these actions bridge the gap between declarative automation inside Salesforce and communication outside Salesforce (people via email, systems via SOAP), they are a favourite source of scenario-based questions. Mastering them also makes you a better admin: you will know when a notification should be an Email Alert rather than a Flow Send Email action, and when an integration can be solved with an Outbound Message instead of asking a developer for Apex.

Part 1: Email Alerts

What an Email Alert Is
An Email Alert is a reusable automation action that sends an email, built from an email template, to a defined set of recipients whenever a triggering automation fires. You create it once in Setup (Setup > Process Automation > Email Alerts) and then reference it from a Workflow Rule, an Approval Process, an Entitlement Process, or a Flow (via the Email Alert action element). The alert itself contains no logic about when to send; that decision belongs to the automation that calls it.

Components of an Email Alert
• Description and Unique Name: identifies the alert; the unique name is used by Flow and the API.
• Object: the alert is tied to one object, and only that object's merge fields (and its parent lookups) can be used in the template and recipient options.
• Email Template: typically a Classic template (Text, HTML with Classic Letterhead, Custom HTML, or Visualforce). Visualforce templates are the choice when you need related lists, conditional content, or child records in the body. Lightning email templates have more limited support in email alerts, so exam answers usually point to Classic or Visualforce templates.
• Recipient Type: you can choose from Account Owner, Account Team, Case Team, Creator, Owner, Email Field (any email field on the record, such as Contact Email), Public Groups, Related Contact, Related Lead or Contact Owner, Related User, Role, Role and Internal Subordinates, Role and Subordinates, Partner User, Portal Role, Customer Portal User, and specific Users.
• Additional Emails: up to five extra email addresses, comma separated, that do not have to be Salesforce users.
• From Email Address: Current User's email address, the Default Workflow User, or a verified Organization-Wide Email Address. The org-wide address is the exam answer whenever a scenario asks for emails to come from a shared address such as support@company.com or when alerts fire from automation with no human initiator.

How an Email Alert Works
1. A record is created or edited (or a time-dependent action or approval step fires).
2. The Workflow Rule, Approval Process, or Flow evaluates its criteria.
3. If criteria are met, the Email Alert action executes: Salesforce resolves the recipient list, merges field values from the triggering record into the template, and queues the email.
4. The email is sent asynchronously. If the recipient list resolves to zero addresses (for example, an empty email field), nothing is sent and no error is thrown.

Email Alert Limits You Must Know
• Each org can send 1,000 email alerts per standard Salesforce license per day, with an overall org ceiling of 2,000,000 per day.
• Developer Edition and trial orgs are limited to 15 email alerts per day.
• Email alerts use the workflow email limit, not the single-email (Send Email) limit of 5,000 per day. This distinction is a classic exam trap when comparing an Email Alert action with Flow's Send Email core action.
• When the daily limit is reached, remaining alerts are not sent and the system administrator receives a warning email; the alerts are not queued for the next day.
• A single email alert can be reused by any number of automations on the same object, which is why reusability is the key design advantage.

Email Alerts in Approval Processes
Email Alerts can be attached as Initial Submission Actions, Approval Step Actions (approve or reject), Final Approval Actions, Final Rejection Actions, and Recall Actions. Note the difference between the approver assignment notification (controlled by the Approval Assignment Email Template on the process) and Email Alert actions (which notify anyone you define, such as the submitter or the sales manager).

Email Alerts in Flow
In Flow Builder you add an Action element, choose the Email Alert category, and select your existing alert. You must pass the Record ID of the triggering record so merge fields resolve. The alternative is the Send Email core action, which lets you type recipients and body text directly but does not use templates in the same way and counts against the single-email limit. On the exam, if the scenario stresses a reusable template, merge fields, a role-based recipient list, or an org-wide from address, the answer is Email Alert.

Part 2: Outbound Messages

What an Outbound Message Is
An Outbound Message is a declarative automation action that sends a SOAP XML message containing specified field values from a record to a designated external endpoint URL when triggered. It is Salesforce's native, no-code way to push data to another system in near real time. It is created in Setup > Process Automation > Outbound Messages (or directly as a Workflow Rule action) and can be invoked from Workflow Rules, Approval Processes, and record-triggered Flows via the Send Outbound Message action. It was never available in Process Builder, which is a frequently tested fact.

Components of an Outbound Message
• Object: the message is tied to one object and can include only fields from that object (plus the record ID). It cannot directly include parent or child record fields.
• Endpoint URL: the web service address that will receive the message. HTTPS is strongly recommended and expected on the exam; the receiving server must trust a certificate chain Salesforce recognises.
• User to Send As: the user whose context is used; this matters when Session ID is included.
• Send Session ID: when checked, the message includes a session ID so the receiving system can call back into the Salesforce API to query or update records. Exam scenarios about the external system needing to retrieve additional data point to this option.
• Fields to Send: the specific fields whose values are included in the XML. Keeping the list minimal reduces exposure of sensitive data.
• Protected Component: marks the message as protected within a managed package.
• WSDL: Salesforce generates a WSDL for each outbound message that the external developer uses to build the listener.

How an Outbound Message Works
1. The triggering automation fires and the Outbound Message action is queued.
2. Salesforce sends the SOAP message (up to 100 notifications bundled per message) to the endpoint from Salesforce's published IP ranges, which the receiving firewall must allow.
3. The endpoint must respond with an acknowledgment (Ack = true).
4. If no acknowledgment is received, Salesforce retries for up to 24 hours, with the interval between retries growing to a maximum of about two hours. After 24 hours the message is dropped from the queue.
5. Administrators monitor delivery in Setup under Outbound Messages > View Message Delivery Status (the Outbound Messaging Delivery Queue), where failed messages can be viewed, retried, or deleted.
6. Messages are not guaranteed to arrive in the order they were generated, so the receiving system must be built to handle out-of-order or duplicate deliveries (each notification carries a unique ID for de-duplication).

When to Use Outbound Messages vs. Alternatives
• Use an Outbound Message when the external system can expose a SOAP listener, you need near real-time push of record data, and you want a no-code solution with automatic retry.
• Use Apex callouts (or Flow HTTP Callout / External Services) when the target requires REST or JSON, custom authentication headers, a response that must be processed, or complex payload transformation.
• Use Platform Events or Change Data Capture when multiple subscribers need the data or an event-driven architecture is desired.
• Use an Email Alert when the goal is to notify a human, not integrate a system.

Part 3: Side-by-Side Comparison

Purpose: Email Alert notifies people; Outbound Message notifies systems.
Payload: Email Alert uses a merged email template; Outbound Message uses SOAP XML with selected fields.
Recipient: Email Alert targets users, roles, groups, email fields, up to five additional addresses; Outbound Message targets exactly one endpoint URL.
Where available: both work in Workflow Rules, Approval Processes, and Flow; only Email Alerts were available in Process Builder.
Reliability: Email Alerts send once and are governed by the daily email limit; Outbound Messages retry for 24 hours until acknowledged.
Monitoring: Email Alerts have no delivery queue (check the debug log or ask recipients); Outbound Messages have a dedicated delivery status queue.

Part 4: Exam Tips: Answering Questions on Email Alerts and Outbound Messages

Tip 1: Identify the audience first. If the scenario says notify, inform, remind, or alert a manager, owner, customer, or team, the answer is an Email Alert. If it says send data to, update, synchronize with, or integrate an external system or ERP, think Outbound Message (or Apex if the requirements exceed SOAP).

Tip 2: Watch for the from-address clue. Emails that must appear to come from a shared mailbox, or that fire from scheduled or time-dependent actions with no active user, require an Organization-Wide Email Address that has been verified.

Tip 3: Related records in the email body mean Visualforce. If the question asks to include a list of related opportunity products, case comments, or child records in the email, the only template type that supports it is a Visualforce email template.

Tip 4: Know the numbers. 1,000 email alerts per standard license per day, 2,000,000 org-wide daily cap, 15 per day in Developer Edition, 5 additional email addresses per alert, 100 notifications per outbound message, 24 hours of retry. Questions about emails suddenly stopped sending in the afternoon are about hitting the daily workflow email limit.

Tip 5: Separate email limits. Email Alerts count against the workflow email limit; Flow Send Email and Apex single emails count against the 5,000 per day single-email limit. If an answer choice blames one limit for the other type of email, it is a distractor.

Tip 6: Process Builder never supported Outbound Messages. If a legacy scenario describes a Process Builder process that must call an external SOAP endpoint, the correct fix is to use a Workflow Rule or, in modern terms, a record-triggered Flow with the Send Outbound Message action.

Tip 7: Acknowledgment and retry are Outbound Message hallmarks. If the scenario mentions a receiving server being down for maintenance, the answer referencing automatic retries for 24 hours and the Outbound Messaging Delivery Queue is correct. Remember that after 24 hours the message is permanently dropped.

Tip 8: Session ID equals callback capability. When the external system must query Salesforce for additional details after receiving the message, select Send Session ID and ensure the User to Send As has the required object permissions.

Tip 9: Only fields from the triggering object. If a question asks how to include a parent Account field in an Opportunity outbound message, the declarative answer is to create a formula field on Opportunity that references the Account field and include that formula field, not to expect cross-object fields natively.

Tip 10: Eliminate code-first answers when a declarative tool suffices. The Advanced Administrator exam rewards choosing clicks over code. If an Outbound Message or Email Alert fully meets the stated requirement, an Apex trigger or Apex callout answer is a distractor, even though it would technically work.

Tip 11: Firewall and IP range clues. If an outbound message is failing with connection errors and the endpoint is confirmed working, the likely cause is that the receiving network has not allowed Salesforce's IP address ranges or that the SSL certificate is not trusted.

Tip 12: Reusability is a design principle. When asked how to reduce maintenance for many automations that send the same notification, the answer is to build one Email Alert and reference it from each Workflow Rule, Approval Process, and Flow rather than recreating the recipient list each time.

Quick Review Checklist
• Email Alert = template + recipients + from address, tied to one object, reusable across automations.
• Outbound Message = SOAP XML + endpoint + selected fields, retries 24 hours, monitored in the delivery queue.
• Both are available in Workflow Rules, Approval Processes, and Flow; Outbound Messages never in Process Builder.
• Org-wide email address for shared or automated senders; Visualforce template for related lists.
• Memorise the daily limits and the 24-hour retry window.
• Default to declarative solutions and pick the action that matches the audience: people get Email Alerts, systems get Outbound Messages.