Workflow Email Alert
A Workflow Email Alert is an automated email action in Salesforce that sends a templated message to a defined set of recipients when an automation fires.
Definition
A Workflow Email Alert is an automated email action in Salesforce that sends a templated message to a defined set of recipients when an automation fires. Recipients can include users, roles, public groups, the record owner, related user or contact lookup fields, and up to five plain email addresses. The message body comes from a saved email template, so the content stays consistent every time the alert runs.
Email alerts started life as actions for Workflow Rules and approval processes. Workflow Rules reached end of support on 31 December 2025, and Salesforce now points admins to Flow Builder for new automation. The email alert action itself was not retired. A record-triggered flow can call an existing email alert, which is why this remains a legacy but still working piece of the platform.
How an email alert fires, who gets it, and where it fits after Flow
An action, not a rule
People often blur Workflow Rules and email alerts into one thing, but they are separate objects. A Workflow Rule is the trigger. It watches an object, checks criteria, and decides when to act. An email alert is one of the actions that rule can call, alongside field updates, tasks, and outbound messages. The same alert can be reused by many rules, by approval process steps, and by flows. That separation matters now. When Salesforce ended support for Workflow Rules, the alerts did not go away with them. The email alert action survived the cutover because it is a reusable building block. Each alert stores three things: an email template, a list of recipients, and a From identity. In the Metadata API this is the WorkflowAlert type, with fields like template, recipients, ccEmails, senderType, and senderAddress. Knowing the alert is a standalone action helps you plan a migration. You rebuild the trigger logic in a flow, then point that flow at the alert you already trust. You rarely need to recreate the email content from scratch, which keeps wording, merge fields, and branding intact during the move.
Recipients and the From address
Choosing recipients is where most of the setup time goes. Salesforce gives you several recipient types so you do not hardcode names. You can send to a specific user, a role, a role and its subordinates, a public group, the record owner, or a related lookup field such as the contact or a custom User field on the record. Account, opportunity, and case team roles are options too on the right objects. On top of named recipients you can add up to five free-form email addresses, handy for a distribution list or an external partner. The From identity is set by the senderType value. CurrentUser sends as the person whose action triggered the alert, which is the default. DefaultWorkflowUser sends from the org default workflow user, useful when the triggering user should stay hidden. An organization-wide email address lets you send from a shared, verified address like alerts@yourcompany.com so replies land in one inbox. Pick the From carefully, because reply handling and deliverability both depend on it. A verified org-wide address usually looks more trustworthy to recipients than an individual mailbox.
The email template does the talking
An email alert never holds its own body text. It always references a saved email template, so the words, layout, and merge fields live in one reusable place. Templates come in several flavors. Classic text and HTML templates are simple and fast. Visualforce templates let a developer pull richer data and loop over related records. Lightning email templates use a modern builder and are the direction Salesforce favors today. Whichever type you pick, merge fields let the message speak to the specific record. A field like {!Case.CaseNumber} or {!Opportunity.Name} resolves at send time using the record that triggered the alert. That is what makes one alert serve thousands of records without manual editing. Because the template is shared, a single edit updates every alert and flow that uses it. That is powerful and a little risky. Change a template and you change every message it drives, so review the dependencies first. Pair templates with a letterhead for consistent header, footer, and color styling across your org. Keep the subject line short and specific, since that is what recipients scan first in a crowded inbox.
Daily limits you can actually hit
Email alerts are governed, and busy orgs do hit the ceiling. Salesforce caps workflow and approval email alerts at 1,000 alert emails per standard Salesforce license per organization per day, with an overall org cap of 2 million. Each named recipient and each CC address counts as a separate email against the limit. So an alert with one user recipient plus three additional addresses spends four of your daily allotment per record. Multiply that by a data load that updates thousands of records and the math gets scary fast. When the limit is reached, Salesforce drops further alert emails for the rest of the day and does not queue them for later. There is no retry. That silent failure is the part that bites teams during migrations and bulk updates. Two habits help. First, scope recipients tightly so a single trigger does not fan out to dozens of mailboxes. Second, watch your usage around big jobs and schedule heavy data work for off-peak windows. If you genuinely need higher volume, transactional email through a flow with Send Email or an integrated email service is the better fit than stacking more alerts.
Reusing alerts inside Flow
Flow is the modern home for automation, and it works with your existing alerts rather than against them. In Flow Builder you add an Action element and search for the email alert by name. The flow passes the triggering record into the alert through the Record ID input. In a record-triggered flow you set that input to the $Record variable, which carries the values of the record that started the flow. The alert then resolves its recipients, template, and From address exactly as it did under a Workflow Rule. This is the cleanest migration path for an email-only rule. You recreate the entry criteria as the flow trigger, drop in one Action element, and you are done. The Migrate to Flow tool in Setup automates much of this and even copies the old rule name into the new flow for traceability. Flow also offers a native Send Email action that builds the message inside the flow without a separate alert object. For brand new automation that choice is often simpler. For anything that already runs on a battle-tested alert, reusing it through Flow saves rework and preserves the wording your stakeholders already approved.
When to keep, migrate, or replace
Not every alert needs the same treatment, so triage them. Keep an alert as-is when it still fires from an approval process, since approvals continue to use email alerts as a supported action. Keep it too when a migrated flow already references it and everything sends correctly. Migrate the trigger when the alert was driven by a Workflow Rule, because those rules no longer get support or bug fixes. Rebuild the rule logic in a record-triggered flow and point the flow at the same alert. Replace the alert entirely when you need behavior it cannot offer, such as dynamic recipient lists, conditional content, or sending from data not on the triggering record. In those cases a flow with the Send Email action or a custom Apex email gives you the control an alert lacks. A quick audit helps you decide. List every email alert, note what calls each one, and flag the alerts whose only caller is a retired Workflow Rule. Those are your migration backlog. The rest can stay, which keeps the project small and lowers the risk of breaking a notification someone quietly depends on.
Create a reusable email alert in Setup
Email alerts are created once and then reused by rules, approvals, and flows. Here is how to build one in Setup so a flow or approval can call it.
- Open Email Alerts
In Setup, enter Email Alerts in Quick Find and select it under Process Automation. Click New Email Alert.
- Name it and pick the object
Give the alert a clear description and unique name, then choose the object whose records will trigger it. The object decides which merge fields and recipient types are available.
- Choose the email template
Select an existing template that holds the subject and body. The template supplies all message content, so confirm its merge fields match the chosen object.
- Set recipients and From
Add recipient types such as user, role, owner, or a related contact, and up to five extra email addresses. Set the From address to the current user, the default workflow user, or an org-wide address.
- Save and wire it up
Save the alert, then call it from a record-triggered flow Action element (passing $Record) or from an approval process step.
The saved template that supplies the subject and body; the alert holds no text of its own.
How recipients are chosen: user, role, role and subordinates, public group, owner, or a related user/contact field.
Up to five free-form addresses, each counting separately against the daily email alert limit.
The sender identity: current user, default workflow user, or a verified org-wide email address.
- Each recipient and CC address counts as one email against the 1,000-per-license daily cap; large data loads can exhaust it silently with no retry.
- The alert stores no body text. If the referenced template is changed or deleted, every alert and flow using it is affected at once.
- Workflow Rules that trigger alerts are out of support since 31 December 2025; rebuild the trigger in a flow and reuse the alert rather than leaving it on a rule.
Trust & references
Cross-checked against the following references.
- Email Alert ActionsSalesforce
- Daily Allocations for Email AlertsSalesforce
Straight from the source - Salesforce's reference material on Workflow Email Alert.
Hands-on resources to go deeper on Workflow Email Alert.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Workflow Email Alert?
Q2. What defines the email content?
Q3. Can Flow use email alerts?
Discussion
Loading discussion…