Why Fault Handling Matters

A flow without fault paths is a silent failure waiting to happen. When a Get Records returns zero rows where one was expected, or a DML violates a validation rule, the flow errors out, Salesforce sends an email to the admin listed on the flow, and the user sees a cryptic “unexpected error.”

Good fault handling turns those failures into either recovered transactions or clear, actionable messages. Here are the six patterns that cover real-world needs.

Pattern 1: The Error Log Object

Create a custom object — Flow_Error__c — with fields for flow name, context (record Id, user), error message, stack hint, timestamp.

Every fault path in your org writes a record to this object. Build a Lightning list view filtered to errors in the last 24 hours and make it the home page for your admin team.

This pattern turns scattered email notifications into a searchable, filterable, dashboardable dataset. When something is broken, you see the pattern across flows, not just isolated incidents.

Pattern 2: The Graceful User Message

For screen flows, the default error screen is ugly and doesn’t tell the user what to do. Replace it.

Wire every error-prone element’s fault path to a screen with:

  • A human-readable message (“We couldn’t save your request right now.”)
  • A suggestion (“Please try again in a moment, or contact support with reference ID: {{errorId}}”).
  • A generated error reference ID that also appears in your error log.

Users report the reference ID; you look it up in Flow_Error__c; you have immediate context.

Pattern 3: The Retry Wrapper

For transient failures (timeouts, lock contention, row-lock errors), a simple retry often succeeds.

Structure: loop counter variable (max 3), fault path decrements a retry-available flag, Decision element routes back to the failed element if retries remain. After exhausting retries, route to the final error path.

Use sparingly. Retry is appropriate for transient infrastructure failures, not for business logic errors.

Pattern 4: The Partial-Success Collector

When processing a collection, one bad record should not fail the whole batch.

Structure: loop through the collection. Each iteration wraps its work in a sub-decision. On fault, log the failing record Id to a “failed” collection and continue the loop. At the end, report X succeeded, Y failed, see: [list].

This pattern is essential for anything running from data imports or integrations. A two-record failure in a batch of two hundred shouldn’t block the other 198.

Pattern 5: The Compensation Path

Some multi-step flows create partial state that must be cleaned up on failure — create a record, call an external API, then update a status field. If step 3 fails, step 1’s record is orphaned.

Structure: after each successful side effect, push a “compensation action” onto a variable collection. In the final fault path, loop through compensations in reverse and execute them.

This is poor-man’s saga pattern in Flow. It’s not perfect (if the compensation itself fails, you’re back to manual cleanup) but it prevents most orphan scenarios.

Pattern 6: Surface the Error to the Agent

In Agentforce-triggered flows, the agent needs to know why the flow failed so it can explain to the user. Return structured error output, not a generic exception.

Structure: include output variables success: boolean, userMessage: text, internalMessage: text. The fault path sets them appropriately. The agent reads userMessage to craft a response and ignores internalMessage unless the agent is an internal one that can show technical detail.

Elements That Need Fault Paths

Not every element supports fault paths. Here’s the list of the important ones that do:

  • Get Records
  • Create Records
  • Update Records
  • Delete Records
  • Action calls (Apex, invocable)
  • Subflow calls
  • HTTP callouts
  • External service invocations

For elements without fault paths (Assignment, Decision, Loop, Screen), errors propagate automatically to the flow’s top-level fault path if you’ve defined one via the flow’s properties.

Naming Faults

Every fault path deserves a descriptive name that shows in the debug log. “Fault” is not descriptive. “Fault_Get_Account” is. “Fault_Get_Account_Not_Found” is better.

When you read a debug log six months from now, these names save minutes per issue.

Email Configuration

Flow error emails go to the flow’s designated admin by default. Override this:

  • Setup → Process Automation Settings → Send Process or Flow Error Emails to → Apex exception email recipients, or a specific user.
  • For dev orgs, route to your inbox. For production, route to a shared admin address.

Don’t let flow errors go unseen because they land in one admin’s spam folder.

Custom Exception Objects

For advanced cases — specifically orgs with many production flows — a custom exception object with fields for severity, category, and run-count pays off. You can build validation rules that alert on high-severity errors and Einstein Analytics dashboards that track error rates over time.

Overkill for a dozen flows. Essential at scale.

Testing Fault Paths

Debug mode lets you simulate fault conditions by running against specific records designed to fail. Keep a set of “canary” records in sandbox whose IDs are known to trigger specific faults.

For more rigorous testing, build flow tests that deliberately invoke failing conditions and assert on the fault path output.

Anti-Patterns to Avoid

Catching and swallowing. Fault paths that do nothing but route back to happy flow hide failures. Always log or surface.

Generic “Something went wrong” messages. Users don’t know what to do with these. Be specific about what failed and what they can do.

Retry without limits. A retry loop without a cap eventually hits a governor limit and fails anyway.

Fault paths calling fault-prone actions. Your error handler should not itself be error-prone. Keep fault paths simple.

Frequently Asked Questions

What does Salesforce do if I don’t define a fault path?

The flow stops, the record transaction rolls back, an error email is sent, and the user sees a generic error. Nothing is logged beyond the error email.

Can I email the user instead of the admin?

Yes — fault paths can invoke email alerts or send-email actions that target the running user. Combine with a log entry for admin visibility.

Do fault paths in subflows propagate?

By default, an unhandled fault in a subflow surfaces to the parent flow. Handle faults inside subflows and return structured results; the parent decides what to do.

Can fault handling impact performance?

Minor. The cost of error logging is one DML per error — negligible compared to the cost of missing errors in production.

Share