Sending bulk emails from Salesforce Flow sounds straightforward — until you hit the 5-recipient cap on the Send Email action and your entire automation grinds to a halt. The good news? There are proven ways to send mass emails through Flow without breaking governor limits or burning through your org's daily email quota. This guide walks you through the exact methods, limits, and workarounds that Salesforce admins and developers actually use in production. You'll learn how to pick the right approach for your use case, avoid common pitfalls, and keep your email deliverability high.
Bulk email in Salesforce Flow refers to sending multiple emails to a list of recipients — contacts, leads, or users — using Flow Builder's Send Email action or Email Alert element. Unlike Salesforce's native List Email or Mass Email features (which work through the UI), Flow-based email lets you trigger sends automatically based on record changes, schedules, or user interactions.
The key difference between Flow email and native mass email comes down to automation and control. Native mass email is a manual, UI-driven process limited to 5,000 recipients per day. Flow email, on the other hand, fires programmatically — which means you can build conditional logic, personalize content dynamically, and chain email sends with other business processes like record updates, task creation, or Slack notifications.
That said, Flow email has its own limitations. The Send Email action only supports up to 5 recipients per invocation, and you'll still share the org's 5,000 daily email limit. Understanding these boundaries is the first step to building email automation that actually works at volume.
Not every bulk email scenario calls for Flow. Here's a practical decision framework to help you pick the right tool:
Use Salesforce Flow when:
Use native List Email or Mass Email when:
Use Marketing Cloud or Account Engagement when:
Use custom Apex when:
If your Salesforce setup already includes a marketing automation tool, lean on that for large-scale campaigns. Flow is best for operational and transactional emails tied to business processes.
Before building any email automation in Flow, you need to understand three separate limits — and how they stack together. Missing even one of these causes failed sends, governor limit errors, or silent email drops that are hard to debug.
Every Salesforce org can send a maximum of 5,000 single emails per day (per a rolling 24-hour period). This limit is shared across all methods — Flow, Apex, workflow email alerts, and manual sends. Once you hit it, every email send in the org fails until the counter resets.
Some editions have lower caps. Here's the breakdown:
Salesforce EditionDaily Single Email LimitMass Email Limit (per day)Developer Edition5010Professional Edition1,000250Enterprise Edition5,0001,000Unlimited / Performance5,0005,000
Source: Salesforce Developer Documentation — Governor Limits
This is the one that catches most admins off guard. The Flow Send Email action only lets you add up to 5 recipient email addresses per invocation. If you put the Send Email action inside a loop and try to email 500 contacts one at a time, you'll hit the transaction limit fast (more on that below).
Within a single Apex transaction (which is what a Flow execution runs inside), you can create a maximum of 1,000 SingleEmailMessage objects. That means even if your org allows 5,000 emails per day, a single Flow run can't send more than 1,000. If your flow loops through 1,500 records trying to send an email for each one, it'll fail at record 1,001.
The practical takeaway: if you need to send more than 1,000 emails at once, you'll need to batch the work — either with a Scheduled Flow that processes records in chunks, or with a Batch Apex class called from Flow via an Invocable Action.
A Screen Flow is the most accessible way to give users a "send bulk emails" button without writing code. Here's how to build one that collects contacts from an Account and sends each one a personalized email.
Open Flow Builder and create a new Screen Flow. Start by creating these resources:
Add a Get Records element to pull all contacts related to the Account:
Add a Decision element right after to check whether the collection is empty. If no contacts have email addresses, show a screen message and end the flow. This prevents wasted processing and confusing errors.
Add a Loop element that iterates over contactCollection, assigning each record to currentContact. Inside the loop, add a Send Email action:
Important: Remember the 5-recipient limit per Send Email invocation. In a loop, each iteration sends to one recipient, so this approach works — but you're constrained by the 1,000 transaction limit. For larger lists, jump to the Apex Invocable Action method below.
Before activating, click Debug in Flow Builder. Enter a test Account ID and walk through each element. Check that:
Once testing passes, add the Flow to the Account record page as a Quick Action or button.
Record-Triggered Flows fire automatically when a record is created, updated, or deleted. They're ideal for operational emails — think order confirmations, case escalation notices, or onboarding triggers.
To send an email when a record meets specific criteria:
Bulkification tip: When a Data Loader updates 200 Case records at once, the Record-Triggered Flow fires for all 200. If your flow isn't designed for bulk, you'll hit limits. The async path helps here — Salesforce batches the asynchronous actions and handles governor limits more gracefully than the immediate path.
For high-volume triggers, pair the Record-Triggered Flow with a Platform Event. Publish an event from the Flow, and have an Apex trigger subscriber send the emails in batch. This pattern decouples the email send from the record transaction entirely.
Scheduled Flows run at a set time and process a batch of records — perfect for digest emails, weekly summaries, or reminder campaigns.
Here's how to set one up:
Salesforce processes Scheduled Flow records in batches of 200 automatically. If your query returns 2,000 opportunities, the platform splits them into 10 batches. Each batch gets its own transaction with fresh governor limits, which means you can effectively send to far more recipients than a single Screen Flow allows.
One caveat: Scheduled Flows still share the 5,000 daily org-wide email cap. If you're sending 3,000 emails via a Scheduled Flow at 8 AM, and your support team sends 2,500 case notifications throughout the day, you'll exhaust the limit by mid-afternoon. Plan your send volumes accordingly.
The Send Email action's 5-recipient cap is a hard limit on the Flow element itself. But you can bypass it entirely by calling a custom Apex class from your Flow using an Invocable Action.
Here's how it works: you create an Apex class with an @InvocableMethod annotation that accepts a list of email addresses (or record IDs) from the Flow, builds SingleEmailMessage objects in bulk, and sends them with Messaging.sendEmail().
A simplified example of the Apex class:
public class FlowBulkEmailSender {
@InvocableMethod(label='Send Bulk Emails' description='Sends emails to a list of addresses from Flow')
public static void sendBulkEmails(List<EmailRequest> requests) {
List<Messaging.SingleEmailMessage> emails = new List<Messaging.SingleEmailMessage>();
for (EmailRequest req : requests) {
for (String addr : req.emailAddresses) {
Messaging.SingleEmailMessage msg = new Messaging.SingleEmailMessage();
msg.setToAddresses(new List<String>{addr});
msg.setSubject(req.subject);
msg.setPlainTextBody(req.body);
if (req.orgWideEmailAddressId != null) {
msg.setOrgWideEmailAddressId(req.orgWideEmailAddressId);
}
emails.add(msg);
}
}
if (!emails.isEmpty()) {
Messaging.sendEmail(emails);
}
}
public class EmailRequest {
@InvocableVariable(required=true label='Email Addresses')
public List<String> emailAddresses;
@InvocableVariable(required=true label='Subject')
public String subject;
@InvocableVariable(required=true label='Body')
public String body;
@InvocableVariable(label='Org-Wide Email Address ID')
public String orgWideEmailAddressId;
}
}
Once deployed, this Invocable Action appears in Flow Builder under the Action element. You pass it your collection of email addresses, subject, and body — and it handles the bulk send without the 5-recipient limitation of the native Send Email action.
Why this pattern wins: The Invocable Method runs inside the Flow's transaction context but isn't bound by the Send Email element's per-invocation limit. You're only limited by the 1,000 SingleEmailMessage per transaction cap and the 5,000 daily org cap.
For sends larger than 1,000, wrap the logic in a Database.Batchable class that the Invocable Method kicks off. The batch processes records in chunks of 200, each with its own transaction limits. This pattern works for teams at organizations that handle complex Salesforce platform customization regularly.
Using email templates instead of hardcoded text makes your Flow emails easier to maintain, brand-consistent, and personalizable. Salesforce supports several template types — each with different capabilities in Flow.
The Send Email action in Flow natively supports Classic Email Templates. You can reference a template by its ID, and Salesforce will automatically merge fields based on the recipient record. Visualforce templates offer the most flexibility — they support conditional logic, related lists, and complex formatting — but they require some markup knowledge.
Lightning templates work with the Salesforce Lightning platform and support Enhanced Letterheads for consistent branding. You can use them with the Send Email action, though you'll need to reference them by their Developer Name rather than their ID in some configurations.
Merge fields let you insert record-specific data into your emails — the recipient's first name, account name, opportunity amount, or any field accessible from the template's related object. In Flow, you can also use Flow variables in the subject and body fields directly, giving you an extra layer of personalization beyond what templates offer alone.
Pro tip: combine template-based structure with Flow variable overrides for the subject line. This lets marketing control the email body through templates while admins can dynamically adjust the subject based on Flow logic — like adding "URGENT:" based on a priority field.
Sending emails from Salesforce Flow means nothing if they land in spam folders. Here's what you need to configure to keep deliverability high.
SPF (Sender Policy Framework): Add Salesforce's IP ranges to your domain's SPF record. This tells receiving mail servers that Salesforce is authorized to send on behalf of your domain. Without it, your emails get flagged or rejected.
DKIM (DomainKeys Identified Mail): Enable DKIM signing in Salesforce Setup under Email Administration. DKIM adds a cryptographic signature to outgoing emails, verifying they haven't been tampered with in transit. This directly improves inbox placement rates.
DMARC: Set up a DMARC policy for your domain that aligns with your SPF and DKIM configuration. DMARC tells receiving servers what to do when authentication fails — quarantine, reject, or allow. A well-configured DMARC record, along with SPF and DKIM, can push your inbox placement above 95%.
Org-Wide Email Addresses: Configure these in Setup → Organization-Wide Email Addresses. When used in the Send Email action, they replace the sender's personal email with a shared business address (e.g., support@yourcompany.com). This looks more professional and consolidates replies to one inbox. It also prevents your users' personal emails from getting flagged as spam when sending in bulk.
In our experience working across 75+ Salesforce projects, email deliverability issues account for roughly 30% of email automation support tickets. Getting SPF, DKIM, and Org-Wide Addresses right from the start saves significant debugging time later. If you're unsure about your current configuration, a Salesforce engineering partner can audit it quickly.
One of the most common questions about Flow emails is: "Where do they show up after sending?" The answer depends on how you configure the Send Email action.
If you set the Log Email on Send parameter to true (it's false by default in some configurations), Salesforce creates an EmailMessage record and logs it in the recipient's Activity History on the Contact, Lead, or related record. This is essential for sales and service teams — they need to see what emails went out without digging through Flow execution logs.
To build reports on Flow-sent emails, create a report using the Email Messages report type. Filter by the sender (the Org-Wide Email Address or the running user) and the date range. You can track open rates and click-through rates if you've enabled HTML email tracking in your org's deliverability settings.
If email logging isn't showing up, check these three things:
Email sends fail. Addresses bounce, org limits get hit mid-batch, and templates throw merge errors when a field is null. Without proper fault handling, these failures crash your entire Flow — which means no emails get sent, even to valid recipients.
Here's how to build resilient email Flows:
Add Fault Paths to every Send Email action. In Flow Builder, click on the Send Email element and drag the Fault connector to a separate path. On this path, add a Create Records element that logs the failure to a custom object (e.g., "Email Error Log") with the recipient address, error message ({!$Flow.FaultMessage}), and timestamp.
Use Decision Elements to pre-validate data. Before the Send Email action, add a Decision that checks whether the email address is not null, the email template exists, and any required merge field values are populated. This catches 80% of potential failures before they trigger a fault.
Build a retry mechanism. For transient failures (like hitting the daily email limit mid-batch), create a Scheduled Path that retries failed sends the next day. Query your Email Error Log for records with "DAILY_LIMIT" in the error message and reprocess them.
Send admin notifications on failure. When a critical email Flow fails — like a customer-facing onboarding sequence — the admin needs to know immediately. Add a separate Send Email action on the fault path that notifies the admin or a Slack channel (via Slack Action) with the error details.
Automated emails still have to follow the law. Here's what to know:
CAN-SPAM Act (US) requires every commercial email to include a physical mailing address and a working unsubscribe mechanism. For Flow-sent emails, this means your email template must include your company address and an opt-out link. Salesforce's native unsubscribe handling (as documented in the Salesforce community) works with List Email but does not automatically apply to emails sent via the Send Email action in Flow. You'll need to include an unsubscribe link manually — either linking to a custom web page that updates the contact's "Email Opt Out" field, or using a Flow-powered form.
GDPR (EU/UK) adds additional requirements: you need documented consent before sending marketing emails, and recipients must be able to withdraw consent easily. If your Salesforce org stores EU contacts, add a consent check to your Flow before the email send. Query the contact's consent status (a custom field or the standard "HasOptedOutOfEmail" field) and skip the send if consent isn't recorded.
Practical implementation: Create a reusable Subflow called "Email Compliance Check" that accepts a Contact ID, checks the Email Opt Out field and any custom consent fields, and returns a boolean. Call this Subflow before every email send in your Flows. This centralizes your compliance logic — update it once, and every Flow that uses it stays compliant. This approach reflects how experienced Salesforce engineering teams handle compliance across the org.
The Send Email action limits you to 5 recipients per invocation. To send more, use a Loop element with the Send Email action inside it (one email per iteration, up to 1,000 per transaction), or build a custom Apex Invocable Action that uses Messaging.sendEmail() to send in bulk without the per-invocation cap.
The Send Email action is a Flow-native element that lets you compose emails directly in Flow Builder with dynamic recipients, subjects, and bodies. An Email Alert is a Workflow action that references a pre-built email template and a specific recipient field — it's less flexible but simpler for basic notifications. Email Alerts count against the workflow email limit (1,000 per day per standard license), not the single email limit.
Not directly through the standard Send Email action. To include attachments, you'll need an Apex Invocable Action that builds the email with Messaging.SingleEmailMessage and attaches files using setFileAttachments() or setEntityAttachments() for ContentVersion-based files.
In the Send Email action, set the "Email Template ID" field to the ID of your Classic Email Template. You can hardcode the ID or store it in a Custom Label for easier maintenance. The template's merge fields will resolve based on the Target Record ID you provide (typically the Contact or Lead ID).
Only if you set the "Log Email on Send" option to true in the Send Email action configuration. When enabled, Salesforce creates an EmailMessage record linked to the recipient's Activity Timeline. Without this setting, the email sends but leaves no trace on the record.
The Send Email action's body field supports rich text. Toggle the body type to "Rich Text" (not plain text) in the action configuration, and you can include HTML formatting, links, and basic styling. For more complex HTML layouts, use an HTML or Visualforce email template referenced by its ID in the Send Email action.
Yes. Use a Get Records element to query the custom object and pull the email field into a variable. Then use that variable as the recipient in the Send Email action. For templates, you'll need a Visualforce email template that supports the custom object, or build the email body directly in Flow using merge variables.
The Flow throws a fault. If you don't have a Fault Path configured on the Send Email action, the entire Flow fails and rolls back any DML operations in the same transaction. With a Fault Path, you can catch the error, log it, notify an admin, and let the rest of the Flow continue.
Building bulk email automation in Salesforce Flow is powerful — but the governor limits, compliance requirements, and deliverability configurations add complexity that catches teams off guard. Getting the architecture right from the start prevents failed sends, compliance violations, and frustrated end users.
At Minuscule Technologies, we've built email automation solutions across 75+ Salesforce projects for enterprises in manufacturing, banking, real estate, and healthcare. Whether you need a simple Flow-based email notification or a full-scale Apex bulk email engine, our 160+ Salesforce engineers can design, build, and deploy it. Book a free consultation to talk through your email automation needs.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
