Email Limits: DailyWorkflowEmails vs SingleEmail Explained

Analyzing Salesforce Email Governor Limits Post-Spring '19

For developers and architects designing high-volume email solutions on the Salesforce platform, understanding how different email sending mechanisms are capped is crucial. The traditional understanding of limits, particularly involving DailyWorkflowEmails, often clashes with real-world execution, especially in organizations updated post-Spring '19 release.

The Recipient Type Dictates the Limit

Testing and observation confirm that the primary differentiator for email governor limits is the recipient type, rather than the invoking automation context (i.e., Apex, Flow, or Workflow Rules).

1. Internal Salesforce User Recipients: Emails sent exclusively to users within the Salesforce organization (whose User records exist) count only against the DailyWorkflowEmails limit.
2. External Recipients: Emails sent to any external address, including standard Contact/Lead emails, hardcoded external email addresses, or recipients sourced from external objects, count against both DailyWorkflowEmails and the more restrictive SingleEmail limit.

This means that using Messaging.sendEmail() in Apex, or any action in Flow that targets an external address, contributes to the shared SingleEmail cap.

Governor Limits Deep Dive

The two relevant daily limits are:

• DailyWorkflowEmails: Primarily tracks emails triggered by Workflow Rules or Flows targeting internal users. However, as noted above, external sends also increment this counter.
• SingleEmail (Shared Limit): This limit (typically 5,000 per rolling 24 hours, though configuration dependent) is the critical constraint for external communications. Any email dispatched to an external recipient contributes to this total, regardless of whether it originated from Apex (using Messaging.sendEmail), Flow, or Process Builder.

Crucially, there is no mechanism to bypass this shared SingleEmail cap for external recipients by segmenting automation types. An Apex callout sending 100 emails to external contacts consumes the same pool as a Flow sending 100 emails to external contacts.

For developers leveraging Messaging.sendEmail() in Apex, the method signature itself does not inherently 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 solutions requiring high-volume external email delivery (e.g., transactional notifications, large batch communications):

• Do not rely solely on DailyWorkflowEmails as an indicator of overall sending capacity. The SingleEmail limit is often the true bottleneck.
• If throughput exceeds the hard limits, developers must integrate with external Email Service Providers (ESPs) via callouts, bypassing the native Salesforce email governor limits entirely.
• When designing complex automation streams, architects must track usage against the shared SingleEmail limit across all asynchronous and synchronous processes targeting non-users.

Key Takeaways

• Email governor limits are enforced based on recipient type (Internal User vs. External Address), not the sending mechanism (Flow vs. Apex).
• Emails to external recipients consume both the DailyWorkflowEmails counter and the shared SingleEmail counter.
• The SingleEmail limit is the critical constraint for external email volume and must be actively monitored across all automation layers.