How to handle errors in a Flow that sends automated emails?

Posted by Vinay Vernekar 26th December 2025

Why error handling matters for email Flows

Automated emails are critical for notifications, approvals, and transactional communication. Failures — due to invalid addresses, governor limits, permission issues, or external mail delivery problems — can break business processes and create poor user experience. A robust error-handling strategy in Salesforce Flow helps you detect failures, contain damage, notify stakeholders, and enable retry or remediation.

Key principles

Design your Flow to be resilient, observable, and recoverable:

  • Resilient: prevent a single failure from rolling back unrelated work.
  • Observable: capture enough diagnostic data for troubleshooting.
  • Recoverable: provide manual or automatic retry/compensation paths.

Practical patterns to handle errors

Below are proven patterns you can implement immediately.

1) Use Fault connectors (the primary Flow mechanism)

Every data element (Get, Create, Update, Delete), Apex action, or Action in Flow supports a Fault connector. Connect that Fault path to a handling subflow or element that:

  • Creates an error log record (custom object e.g., Error_Log__c), capturing context like failed element, input record Id, timestamp and error message.
  • Sends a high-priority notification to an admin or support queue (email or Chatter).
  • Sets a flag on the related record (e.g., Email_Status__c = 'Failed') so business users can see failures in the UI.

2) Centralize handling with a Subflow

Create a reusable “Error Handler” autolaunched subflow that accepts inputs like ContextObjectId, ElementName, and ErrorMessage. From every Fault connector, call this subflow. Centralization simplifies updates and reporting.

3) Persist error details to a custom object

Use a custom object (Error_Log__c) with fields for:

  • Source_Element__c
  • Record_Id__c
  • Error_Message__c
  • Flow_Name__c
  • Retry_Count__c

Persisting errors lets you build reports/dashboards and implement bulk retries.

4) Ensure logs survive rollbacks

If your Flow is part of a larger transaction that might be rolled back, consider logging the error in a separate, guaranteed transaction. Two options:

  • Call an invocable Apex that enqueues a Queueable or @future job to create the log — this runs in a separate transaction.
  • Publish a Platform Event from the Fault path and have a trigger or Process Builder subscribe and write the log.

Sample Invocable Apex (Queueable) to log error in separate transaction

public class ErrorLogger implements Queueable {
private String recordId;
private String message;
public ErrorLogger(String recordId, String message){
this.recordId = recordId;
this.message = message;
}
public void execute(QueueableContext ctx){
Error_Log__c e = new Error_Log__c();
e.Record_Id__c = recordId;
e.Error_Message__c = message;
insert e;
}
}

5) Retry strategy

Decide when retries make sense:

  • Transient errors: schedule a retry using a Pause element (Schedule) or enqueue a retry job via Apex.
  • Persistent errors (bad email): mark the record and stop retrying. Let users correct data.

6) Notify and enable human remediation

When creating the error log, also notify the support team with a link to the Error_Log__c record and key context. Provide a quick action or Flow screen for support to trigger a retry.

7) Use transactional isolation for outbound email

When possible, perform the email send in a separate transaction from critical DML. If an email fails, you don’t want your business data to rollback. Options:

  • Queue the send with Queueable Apex or Platform Event and process asynchronously.
  • Have the Flow create a “Pending_Email__c” record; a scheduled Apex/Platform Event subscriber actually sends emails and logs outcomes.

8) Monitor and alert

Set up observability:

  • Report on Error_Log__c and Active Flows (Paused and Failed Flow Interviews).
  • Subscribe to Platform Events for email failures.
  • Use Health Check and Email Deliverability settings to catch org-wide issues.

9) Handle common root causes

Examples and mitigations:

  • Invalid email addresses — validate before attempting to send.
  • Exceeded single-email limits — bulk and rate-limit sends; batch via scheduled jobs.
  • Permission or Sharing issues — run the send logic in system context (Apex) or ensure the Flow’s running user has access.
  • Deliverability or external SMTP issues — integrate with external email providers and implement retries/backoff.

10) Test thoroughly

Create sandbox scenarios that simulate failures (bad addresses, DML exceptions, Apex exceptions) and confirm that Fault paths capture and log the issues properly. Validate retry behavior and ensure logs are actionable.

Putting it together — an example flow

High-level steps:

  1. Flow receives a trigger (record change or scheduled).
  2. Validate email address (Decision). If invalid -> mark and stop.
  3. Create a Pending_Email__c record and hand off to asynchronous sender (Apex queue or Platform Event).
  4. Asynchronous sender attempts send; on success it updates the original record; on failure it calls the Error Logger (Queueable) and increments Retry_Count.
  5. Support team reviews Error_Log__c reports or uses the Flow’s retry quick action.

Conclusion

Handling errors in a Flow that sends automated emails is about separating concerns, capturing rich diagnostics, and providing clear retry and remediation paths. Use Fault connectors to catch exceptions, persist logs (preferably in a separate transaction), notify stakeholders, and implement retries when appropriate. Combining Flow patterns with lightweight Apex or Platform Events delivers a robust, maintainable solution.

Tags: