Flow Reliability & Operations

A Flow fault connector is not an error-handling strategy

JSBC Labs25 September 20268 min read

A connector changes the path, not the operating model

Adding a fault connector to every data or action element can make a Flow diagram look production-ready. It is still only a routing mechanism. Salesforce describes a fault connector as the path executed when its source element produces an error. That tells the interview where to go next; it does not decide whether the business operation should be abandoned, reversed, retried or accepted with incomplete side effects.

Error handling begins with those decisions. The designer must define what outcome remains safe after each failure, which transaction state can be trusted and who owns recovery. Without that model, a fault path often turns a visible failure into a quiet partial success—the most expensive kind of automation defect.

Classify failures before designing the response

Not every Flow failure means the same thing. A validation rule rejection is a business-data problem. A missing permission is an identity or deployment problem. A duplicate-value error may be a concurrency or idempotency problem. A callout timeout is an uncertain integration outcome. A governor-limit failure points to workload design. Sending all of them to one ‘log and continue’ subflow discards the distinction needed for safe recovery.

Create a small failure taxonomy for critical automations: rejected business input, configuration defect, authorisation failure, transient dependency, resource exhaustion and unexpected platform fault. For each category define whether to stop, compensate, retry, queue for review or escalate. The categories should drive the path, message and alert—not the convenience of a generic error screen.

Decide atomicity before drawing the Flow

Ask a blunt question: if the third step fails, should the first two changes exist? For an approval submission, partial state may be unacceptable. For a customer onboarding process, saving the core record while marking a downstream notification for recovery may be preferable to losing the entire request. Both can be valid, but the decision must be deliberate.

The answer depends on Flow type, transaction boundaries and the element that failed. Record-triggered automation also participates in Salesforce's wider order of execution. Document which work is synchronous, which work is deferred and which side effects sit outside the Salesforce transaction. Then test the actual commit or rollback behaviour. A diagram that merely ends in a red connector is not evidence of atomicity.

Do not put the only evidence inside the failing transaction

A common pattern catches a fault and creates an Error Log record. That is useful until the original problem is a database limit, a permission failure or a condition that also blocks the log insert. If the transaction rolls back, the evidence may disappear with the business change. The organisation is then dependent on an email or a user screenshot to reconstruct what happened.

Use layers of evidence appropriate to the risk. Preserve the Flow name and version, interview identifier where available, triggering record or business key, user, timestamp, failed operation, error text and correlation identifier. For high-value processes, route durable operational signals through a mechanism whose failure domain is not identical to the work being observed. Salesforce Well-Architected guidance emphasises observability and recovery as system qualities, not optional debugging aids.

Separate the user's message from the operator's diagnosis

A screen-flow user needs a concise explanation and a safe next action. An operator needs the technical context, affected records, execution path and ownership. Showing the raw fault message to the user can expose implementation detail without helping them recover; replacing every error with ‘Something went wrong’ leaves support blind.

Design two outputs. The user-facing message should state what was not completed, whether their input was saved and what they should do next. The operational event should retain diagnostic detail and a correlation reference. Put that reference in the user message when support may need it. Do not make either audience search an inbox for an unstructured Flow error email as the primary operating process.

Continuing after a fault is a business decision

A handled fault can tempt designers to rejoin the main path and finish the Flow. Sometimes that is correct: a non-critical notification failed, but the authoritative update succeeded and a recovery item was created. In other cases, continuing can mark a case complete even though a required entitlement, payment instruction or integration request never existed.

Label every element as required, recoverable or best-effort. Required failure stops the business outcome. Recoverable failure creates durable work with a defined service level. Best-effort failure is observable but does not block completion. This classification should appear in requirements and tests. It should not be inferred later from whichever connector the builder happened to draw.

Retries require idempotency and backpressure

Retrying is safe only when another attempt cannot duplicate or corrupt the outcome. A timed-out callout may have completed downstream even though Salesforce did not receive the response. Replaying it without an idempotency key can create two orders, two payments or two service tickets. Likewise, retrying immediately during an outage can multiply load and consume platform capacity.

For recoverable integrations, persist a stable operation key and the intended business request. Define maximum attempts, delay, escalation and reconciliation. Distinguish ‘definitely rejected’ from ‘outcome unknown.’ Salesforce's asynchronous processing guidance shows that different mechanisms carry different limits and execution characteristics; moving work out of the initial Flow is an architectural boundary, not a universal retry button.

Make subflows honest about failure

Reusable subflows often expose output variables such as success and message. That can be a useful contract, but only if the caller cannot accidentally ignore failure. A subflow that swallows every fault and returns blank outputs creates false success upstream. A parent that catches every subflow fault in the same way loses domain-specific recovery.

Define inputs, outputs, side effects and failure semantics for each reusable subflow. Return structured business outcomes where the caller can legitimately choose a response; allow unrecoverable technical failures to remain visible. Keep logging helpers small and defensive. Reuse should standardise evidence and routing, not erase the meaning of the failure.

Test the failure path, not only the happy path

Salesforce supports automated tests and assertions for record-triggered flows. Use them to verify business outcomes, and supplement them where necessary with Apex and integration tests that can force dependency, permission and DML failures. A successful debug run with an administrator identity says little about how the automation behaves for a least-privilege user or a bulk transaction.

For each critical path, prove what commits, what rolls back, what the user sees, what evidence is retained and what recovery work is created. Test mixed-record batches, duplicate requests, unavailable dependencies, missing configuration and repeated attempts. Also test the error handler itself. A fault path that fails while reporting the first fault should still leave an observable signal.

Operate Flow as a service

Give every business-critical automation an owner, severity model and response procedure. Monitor failure rate and age of unrecovered work, not just the arrival of error emails. Record the Flow version and deployment that changed behaviour. Review recurring failures as design feedback: frequent validation rejections, permission faults or timeouts are signals about the process, not background noise to archive.

The JSBC Labs view is that a fault connector is necessary plumbing, not reliability architecture. Start with the promised business outcome, define atomicity and failure categories, design durable evidence, separate communication from diagnosis, make retries idempotent and test recovery under realistic identities and workloads. A Flow is reliable when the organisation can explain and recover its failures—not when every element has a red line attached.