--- title: "Flow record triggered types" url: "https://trailassembly.com/flow-record-triggered-types/" topic: "Flow and Automation" published: "2026-09-20T07:49:14+00:00" updated: "2026-10-06T13:59:26+00:00" --- # Flow record triggered types **The short version:** there is one record-triggered flow with four places work can run. Before save is for setting fields on the record being saved and nothing else. After save is for touching other records, sending things, and calling actions. The asynchronous path is for anything that must not hold up the user, callouts above all. Scheduled paths are for work that happens later on the clock. Pick the earliest one that can do the job. ## Before save Configured by choosing “Fast Field Updates” when you create the flow. It runs while the record is in flight, before it hits the database, so assigning to a field on `$Record` is enough. No Update Records element, no second save, no re-running of the whole save order. The trade is a short list of allowed elements. You get Assignment, Decision, Get Records, Loop, and the collection elements. You do not get Create, Update or Delete on other records, you do not get Action elements, and you cannot send an email or call Apex. `$Record__Prior` is not available either, so change detection belongs in the entry criteria. Use it for stamping, defaulting, normalising text, and copying a parent value onto the record. It is the fastest thing in the automation toolbox because it skips an entire save cycle. ## After save Chosen with “Actions and Related Records”. The record is saved, the Id exists, and the flow can do essentially anything: create related records, update the parent, call an invocable Apex action, post to Chatter, send an email. `$Record__Prior` is populated on update and null on insert, so old-versus-new comparisons live here. The cost is a second save when you update the triggering record from an after-save flow, which re-runs validation rules, roll-ups and other automation on that record. If all you wanted was to set a field on the record that triggered the flow, you have built the slow version of a before-save flow. ## The asynchronous path An after-save flow can branch to a path marked to run asynchronously. It executes in a separate transaction after the original one commits, with its own governor limits. Two reasons to use it. Callouts, because the platform will not let you make an HTTP callout after DML in the same transaction, and an after-save flow is by definition after DML. And latency, because work on the async path does not sit between the user and their saved record. A third, less obvious reason: the async path sees the committed state of the database, so it can query records that other automation created during the original transaction. ## Scheduled paths A scheduled path runs at an offset from a moment you choose: a number of days or hours before or after a date field on the record, or after the record is created or updated. It runs in its own transaction, in batches, well after the user has gone. Scheduled paths are re-evaluated when they fire. If the record no longer meets the criteria you set on the path, the work is skipped, which is what you want for a “chase this if it is still open in three days” pattern. Records queued on a scheduled path are visible in Setup under the flow’s scheduled path entries, and the batch size is configurable in Process Automation Settings. ## Choosing one - Setting a field on the record that triggered the flow: **before save**. No exceptions worth making. - Creating or updating other records, emails, Apex actions: **after save**. - Anything that calls out to another system: **asynchronous path**. - Anything with the word “later”, “reminder”, or “if it is still” in the requirement: **scheduled path**. - Blocking a save with a message: a Custom Error element, in a before-save flow where possible. ## One flow or several You can put all four path types in a single flow on an object, and you can also build several flows on the same object with different entry criteria. Both are defensible. The argument for fewer flows is that order between them is governed by the trigger order value you set on each, and that is one more thing to maintain. The argument for more is that a flow with six branches and four scheduled paths becomes unreviewable. ## Frequently asked **Can a before-save flow stop a save?** Yes, with a Custom Error element. That is the cheapest place to block a bad record. **Does the async path run if the transaction fails?** No. It is queued when the transaction commits, so a rollback means it never runs. **How do I control which flow runs first on an object?** Set the trigger order on each record-triggered flow. Flows without a value run after those with one, in no guaranteed order. --- Source: https://trailassembly.com/flow-record-triggered-types/ Trail Assembly — independent Salesforce write-ups.