Salesforce email governor limits after Spring '19
Salesforce single email capacity is determined strictly by recipient type rather than the automation mechanism used to send the message. Any email dispatched to external recipients—whether via Apex Messaging.sendEmail, Flow, or Process Builder—draws from a shared SingleEmail limit of typically 5,000 per rolling 24 hours. In contrast, emails targeting internal users consume only the DailyWorkflowEmails allowance, leaving your SingleEmail capacity intact.
The recipient type dictates the limit
Testing and observation both point the same way. What drives the email governor limit is the recipient type, not the automation context that invoked the send, so Apex, Flow and Workflow Rules land in the same place.
- Internal Salesforce user recipients: email sent only to users inside the org, the ones with User records, counts against the
DailyWorkflowEmailslimit alone. - External recipients: email sent to any external address, including standard Contact and Lead emails, a hardcoded external address, or recipients sourced from external objects, counts against both
DailyWorkflowEmailsand the tighterSingleEmaillimit.
So Messaging.sendEmail() in Apex, or any Flow action aimed at an external address, feeds the shared SingleEmail cap.
The two daily limits
DailyWorkflowEmailstracks email triggered by Workflow Rules or Flows aimed at internal users. As above, external sends increment it too.SingleEmailis the shared one, typically 5,000 per rolling 24 hours, though that depends on configuration. It is the constraint that bites on external communication. Any email dispatched to an external recipient adds to the total, whether it came from Apex throughMessaging.sendEmail, from Flow, or from Process Builder.
You cannot get around the shared SingleEmail cap for external recipients by splitting the work across automation types. An Apex callout sending 100 emails to external contacts draws on the same pool as a Flow sending 100 emails to external contacts.
In Apex, the Messaging.sendEmail() signature does nothing to override the system-level tracking:
List<Messaging.SingleEmailMessage> messages = new List<Messaging.SingleEmailMessage>();
// ... populate messages list ...
// If recipients in 'messages' include external addresses, both DailyWorkflowEmails and SingleEmail are incremented.
Messaging.sendEmail(messages, false);
Architectural implications
For anything that has to deliver external email at volume, such as transactional notifications or large batch communications:
- Do not read
DailyWorkflowEmailsas a measure of your overall sending capacity.SingleEmailis usually the real bottleneck. - If throughput goes past the hard limits, integrate an external Email Service Provider through callouts, which leaves the native Salesforce email governor limits out of the picture.
- In complex automation streams, track usage against the shared
SingleEmaillimit across every synchronous and asynchronous process that targets non-users.
Leave a Comment