--- title: "Flow async path" url: "https://trailassembly.com/flow-async-path/" topic: "Flow and Automation" published: "2026-09-20T04:56:02+00:00" updated: "2026-10-06T13:59:15+00:00" --- # Flow async path **In one sentence:** the asynchronous path is a branch of an after-save record-triggered flow that runs in its own transaction once the original one has committed, which buys you a fresh set of governor limits, the ability to make HTTP callouts, and a save that does not make the user wait. The price is that nobody is watching when it fails, so the error handling has to be built deliberately. ## What it is Open an after-save record-triggered flow, add a path on the Start element, and set it to run asynchronously. Everything on that path executes separately from the save that triggered it. The user’s record is already committed by then, and their browser has already moved on. It is not a scheduled path. There is no offset and no date field. The async path is queued as soon as the transaction commits and runs as soon as the platform gets to it, which is usually seconds but is explicitly not guaranteed. Treat it as “soon”, never as “immediately”. ## Why callouts have to live here Salesforce does not allow an HTTP callout after a DML statement in the same transaction. An after-save flow runs after the record has been written, so any callout you attempt on the immediate path fails with an uncommitted work pending error. Moving the callout to the async path solves it cleanly, because the async path starts a new transaction with no pending work. This is the standard shape for a flow that pushes a record to an external system: - Entry criteria on the flow narrow it to the records worth sending. - An async path holds the HTTP Callout action or the invocable Apex that wraps it. - A fault connector off the callout writes an integration log record and, if the failure is retryable, stamps a field a later job can pick up. ## The other reasons to use it **Fresh limits.** The async transaction gets its own SOQL and DML allowance, and asynchronous transactions get a larger heap and CPU allowance than synchronous ones. Work that pushes a busy save over the edge can be moved off the critical path. **Committed data.** The async path queries the database as it stands after everything in the original transaction has finished. If your logic depends on records that another trigger or flow created during that save, the async path can see them and the immediate path may not. **Mixed DML.** Setup objects and non-setup objects cannot be written in the same transaction. Creating a User or a permission set assignment in reaction to a record save is a classic use for the async path. ## Error handling with nobody there This is where async paths go wrong. When the immediate path throws, the save fails and the user sees something. When the async path throws, the record is already saved, the user has gone, and the only signal is a flow error email sent to whoever is configured in Process Automation Settings. That address defaults to the flow’s last modified user, which means your integration alerts follow whoever last opened the flow in Builder. Build the following into every async path: - A fault connector on every element that can fail, not just the callout. A Get Records that returns nothing does not throw, but an Update Records against a record someone deleted does. - A custom logging object, written from the fault path, holding the record Id, the element, and `{!$Flow.FaultMessage}`. Email is not a monitoring system. - A status field on the record itself when the outcome matters to users, so support can answer “did it send?” without reading logs. - An explicit decision about retries. Flow will not retry for you. Either stamp the record for a scheduled flow to pick up, or accept the loss and say so in the design. ## Testing it The debug dialog for a record-triggered flow includes an option controlling whether asynchronous paths run as part of the debug run. Turn it on when you are testing the path itself, and remember that a callout on an async path in a sandbox will hit whatever endpoint the named credential points at. Rollback in debug does not unsend an HTTP request. ## Frequently asked **Does the async path run as the user who saved the record?** It runs in the same user context as the flow that queued it, but there is no session and no screen, so anything that needs user interaction is off the table. **Can I guarantee ordering between two async paths?** No. They are queued independently and may run in any order. If order matters, put both steps on the same path. **What happens if the original save rolls back?** The async path is never queued. It only exists once the transaction commits. --- Source: https://trailassembly.com/flow-async-path/ Trail Assembly — independent Salesforce write-ups.