Email Notification
An Email Notification in Salesforce is an automated message dispatched by the platform to inform users about a system event, record change, task assignment, approval step, or any business condition an administrator has configured.
Definition
An Email Notification in Salesforce is an automated message dispatched by the platform to inform users about a system event, record change, task assignment, approval step, or any business condition an administrator has configured. It is the most common form of out-of-band communication the platform produces, and every org sends thousands of them per day across automation tools, system events, and user-driven actions.
Email notifications are produced by several different mechanisms inside Salesforce, each with its own configuration surface and delivery limits. The same notification might originate from a Flow, a Workflow Rule, an Approval Process, a Case Assignment Rule, an Apex method, or a built-in platform event such as a password reset. Understanding which mechanism sent which email is the first step in debugging delivery, formatting, and reputation issues.
Where email notifications come from inside Salesforce
Flow Send Email and Email Alerts
The modern home for declarative email notifications is the Flow Builder. The Send Email action accepts a recipient address (single or collection), a subject, an HTML or plain-text body, and optional attachments. For richer formatting and admin reuse, Flows can also invoke an Email Alert defined in Setup. Email Alerts wrap an Email Template, a set of recipients (users, roles, public groups, related contacts), and a sender (current user, default workflow user, or an org-wide email address). The Flow simply references the alert by API name, which keeps recipient and template management in Setup where it belongs.
Workflow Rule email alerts (legacy)
Many orgs still run email notifications through Workflow Rules created years ago. Salesforce stopped accepting new Workflow Rules with the Winter 2023 release, but existing rules continue to fire and most orgs have hundreds of them. When auditing email noise in an org, start by listing every active Workflow Rule and its associated Email Alerts. Migration to Flow is the long-term path because Flow handles bulk processing more cleanly and is on the active development roadmap, but it is not urgent until a rule needs a change.
Approval Process notifications
Every Approval Process sends email notifications at multiple stages: initial submission, each approval step, final approval or rejection, and recall. The recipient list is dynamic based on the approver routing rules. Approval emails contain a one-click approve and reject link signed with a per-user token, which means delivery problems on these emails directly block business processes. Bounced approval emails are one of the most common causes of stuck records in queues, so monitoring delivery on the Approval Process side specifically matters more than on most other notification types.
Task, Event, and assignment notifications
When a record is assigned to a user via a Case or Lead Assignment Rule, by default the assignee receives an email notification with a link to the record. Users can also opt in to email notifications when they are assigned a Task or invited to an Event. These notifications fire from a setting on the user profile (Email Settings) rather than from any automation. Disabling the org-wide setting silences them globally, but most orgs leave them on because they drive engagement with the assigned work.
System notifications: passwords, errors, logins
Some email notifications are not configurable: password reset emails, login email verifications, Apex unhandled exception notices to the developer, and integration callout failures to the Apex Job owner. These platform-produced emails are sent from a non-reply Salesforce address and cannot be reskinned. They count against the org's daily email limit for non-customer recipients, which is shared with custom Apex emails. If the limit is exhausted by automation, password resets can fail silently and users get locked out, which is one of the worst kinds of outage to debug.
Apex email and Send Email Quick Action
Developers send notifications programmatically through Messaging.SingleEmailMessage and Messaging.MassEmailMessage. These calls give code complete control over recipients, attachments, templates, and the bypass-user-email-opt-out flag. The Send Email Quick Action on records (Cases, Opportunities, Leads, Contacts) is a hybrid: it surfaces a composer in Lightning, optionally pre-fills from a template, and sends through the user's signature and the Email Relay configuration. Quick Actions count against the user's daily email limit, not the org's, which is why a busy support team's Cases page can suddenly stop sending email mid-day.
Deliverability, bounce, and reputation
All email notifications flow through the same Salesforce Email Deliverability gate: System Email is on, off, or in System Email Only mode. In a sandbox, this is set to System Email Only by default to prevent test runs from spamming real customers. In production it should be All Email but is sometimes wrong after a sandbox refresh. Bounces, complaints, and unsubscribes are tracked at the contact level. Salesforce uses SPF and DKIM for sender authentication, with optional DMARC enforcement when the customer has set up their own domain via Enhanced Email and DKIM signing keys.
Tracking email noise and reducing it
Most production orgs send far more email notifications than anyone actually reads. The first time the Marketing or Service operations team complains about email fatigue, run an audit: pull a week of Email Logs, group by template and triggering automation, and rank notifications by volume. The top five almost always cover something like Case assignment updates, opportunity stage-change alerts, generic task reminders, weekly digest emails from custom Apex, and approval reminders. For each of the top noisemakers, ask whether the recipient actually acts on the email or whether an in-app notification, a Slack message, or a Chatter post would carry the same signal at lower cost. Replacing one chatty email template with a targeted in-app notification often saves more bandwidth than every other optimization combined. Email is the right channel for things that need to leave the platform; for events that already have a Salesforce surface, push notifications and Chatter mentions land better. Document each retired alert so future admins do not re-introduce the noise three releases later.
Configure an email notification correctly
Most email notification problems are diagnosed by walking back from the recipient to the configuration: who sent it, which template, which automation triggered it, and whether the org's deliverability settings allowed it through. The setup steps below cover the common case: a Flow-triggered notification using an Email Alert. Adjust the steps for Approval Processes, Apex, or Workflow Rules.
- Create or pick the Email Template
From Setup, navigate to Email Templates (Classic Email Templates for legacy automation, or Lightning Email Templates for record-bound Quick Actions). Use Visualforce, HTML, or Text templates per the org's deliverability preferences. Set the From Address to an Organization-Wide Email Address rather than a personal user. Merge fields should reference the triggering record so recipients see the right context, and link URLs should use absolute paths so they work in any client.
- Define the Email Alert
From Setup, open Email Alerts and click New. Choose the Object the alert is associated with, reference the template, and add recipients. Recipients can be users, roles, public groups, related users (Case Owner, Account Owner, Contact Email), or hardcoded addresses (up to five external addresses). Set the From Email Address to a Default Workflow User or an Org-Wide Address. Save and copy the unique name (API name) for use in the Flow.
- Wire the Flow to the Alert
In Flow Builder, drag a Send Email Alert action onto the canvas at the point where the notification should fire. Map the alert API name and the record ID. For more dynamic flows, use Send Email (the raw action) with explicit body and recipient variables. Test the flow in a sandbox with debug enabled, verifying the email appears in the test recipient's inbox and that merge fields resolved correctly.
- Monitor deliverability and adjust
After deployment, open Email Logs (Setup > Email > Email Logs) and request the last 24 hours of logs. The CSV shows every message sent with delivery status, bounce reason, and the user who triggered the send. For ongoing observability, schedule the Email Deliverability dashboard to be exported weekly into a reporting tool and alert on any bounce-rate spike. If the org sends to external customers, enable DKIM signing and align the from-domain to the org's DNS to maintain sender reputation over time.
- Sandbox refreshes set Email Deliverability to System Email Only by default. Test sends will succeed silently but never reach the inbox. Always verify the setting after a refresh.
- Daily email limits are per org for automation-sourced emails (5,000 external addresses per 24 hours by default) and per user for Apex and Quick Action emails. Exhausting the limit blocks password resets too.
- Hardcoded external recipients in Email Alerts cap at five. For larger lists, use a Public Group containing Contact records and reference the group.
- Email merge fields that resolve to null render as empty strings, often resulting in awkward sentences. Use IF formulas in the template to substitute a fallback value.
- Bounce tracking flags the Contact, not the email address used. If the same address appears on multiple Contacts, only the specific Contact is marked bounced and other records continue to send.
Trust & references
Cross-checked against the following references.
- Define Email AlertsSalesforce Help
- Configure Deliverability SettingsSalesforce Help
Straight from the source - Salesforce's reference material on Email Notification.
- Email AlertsSalesforce Help
- Email TemplatesSalesforce Help
- Email LogsSalesforce Help
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 an Email Notification?
Q2. What's a common problem with email notifications?
Q3. What's an alternative to high-volume individual notifications?
Discussion
Loading discussion…