Before-Save vs After-Save Flow in Salesforce

Before-Save vs After-Save: When the Flow Runs

A record-triggered flow fires when a record is created, updated, or (for after-save) deleted. The single most important decision you make when building one is timing — whether the flow runs before Salesforce writes the record to the database or after. That timing isn’t a cosmetic setting; it determines both what the flow is allowed to do and how expensive it is to run.

You set this at the Start element when you configure the trigger. Salesforce doesn’t label the options “before-save” and “after-save” in the UI — since Winter ’22 it describes them by intent: Fast Field Updates (before-save) and Actions and Related Records (after-save). Understanding the before-save vs after-save flow distinction is really about understanding those two phases of the save.

What a Before-Save Flow Can — and Can’t — Do

A before-save flow runs before the record is committed to the database, much like a before Apex trigger but built with clicks. Because the record is still in flight, the flow can set field values on the triggering record directly — no DML required. You simply assign new values to $Record (using an Assignment or an Update Records element), and Salesforce saves them as part of the same write it was already going to perform.

That single fact is the source of the performance gain: there’s no extra save cycle. Salesforce notes a before-save flow can update a record roughly 10 times faster than the equivalent post-save automation, and it doesn’t consume a separate DML operation against your governor limits.

The trade-off is scope. A before-save flow can do one thing only — update fields on the record that triggered it. It cannot:

• Create, update, or delete other records
• Send email alerts, custom notifications, or post to Chatter
• Call Apex actions, invocable actions, or subflows
• Use a scheduled path or an asynchronous path

It also can’t rely on the new record’s Id for an insert — that value doesn’t exist until the record is saved. Both $Record and $Record__Prior are available, so before-save flows are excellent for validation-style fixes, field standardization, and derived values that depend only on the record itself.

What an After-Save Flow Unlocks

An after-save flow runs after the triggering record is saved to the database (but before the transaction commits), comparable to an after Apex trigger. The record now has its Id and its final saved state, which opens up nearly everything a flow can do.

After-save flows can create, update, and delete related records, send email alerts and custom notifications, post to Chatter, call subflows and Apex actions, and integrate with external systems. They’re also the only record-triggered timing that supports scheduled paths (time-based actions) and asynchronous paths (deferring heavier work off the main transaction). This is why most automation that used to live in Process Builder now lives in after-save flows.

The cost is performance. Any change an after-save flow makes — including updating the triggering record itself — requires explicit DML and counts against your DML limits. You won’t notice it on a single record, but in bulk operations a poorly scoped after-save flow adds up. The fix is discipline: tight entry conditions, and offloading non-urgent work to a scheduled or asynchronous path.

Before-Save vs After-Save in the Order of Execution

The timing difference maps directly onto Salesforce’s order of execution, and that’s where the before-save vs after-save flow distinction earns its exam attention. In simplified terms, for a single saved record:

• System validation runs (required fields, field formats, lengths)
• Before-save flows run — the first automation in the order, ahead of before Apex triggers
• Before triggers run, then custom validation rules and duplicate rules
• The record is saved to the database but not yet committed
• After triggers run, then assignment and auto-response rules
• After-save flows run on the saved record — for flows on API v54.0 and later, ahead of workflow rules and entitlement rules
• The transaction commits; post-commit work (emails, asynchronous Apex, async paths) follows

Because before-save flows execute so early — even before custom validation rules — a value you set there is what validation rules and downstream automation actually see. That ordering is a frequent source of “why did my validation rule behave unexpectedly?” puzzles.

How to Choose Between Before-Save and After-Save

The decision collapses to one question: does your logic touch anything other than the triggering record? If the answer is no, use before-save. If the answer is yes — related records, emails, subflows, Id-dependent logic, or deferred work — use after-save.