The Core Difference

A before-save flow runs during the save transaction, before the record is committed. It can modify the triggering record in memory without an additional DML.

An after-save flow runs after the record is committed. It can create related records, send notifications, update other objects, and make callouts — but it costs a DML to update the triggering record.

That single performance difference — DML or no DML — drives most of the decision. The rest flows from it.

What Before-Save Can Do

Before-save is narrow on purpose.

  • Read fields on the triggering record.
  • Update fields on the triggering record. No DML consumed.
  • Get Records from other objects (still costs SOQL).
  • Use Assignment, Decision, and Loop elements.

It cannot:

  • Create or update other records (no DML at all, including on related objects).
  • Send email.
  • Invoke a subflow that performs DML.
  • Make callouts.
  • Call actions that have side effects.

The restriction is the point. Before-save exists to make field updates on the triggering record essentially free.

What After-Save Can Do

Everything before-save can do, plus:

  • Create, update, or delete records on any object.
  • Send email alerts.
  • Invoke actions that perform callouts.
  • Call subflows that do DML.
  • Publish platform events.

After-save’s cost: updating the triggering record from an after-save flow consumes one extra DML per record processed.

The Decision Rule

If all you need to do is modify fields on the triggering record based on other fields on the same record, use before-save. Every time.

If you need to touch any other record, send any communication, or make any callout, use after-save.

That’s the rule. Everything else is edge cases.

Concrete Examples

Use before-save:

  • Auto-populate a Priority field based on Account tier and Case type.
  • Set a lowercase version of the Email field for case-insensitive matching.
  • Calculate a total from other fields on the same record.
  • Enforce a default value when a required field is blank.

Use after-save:

  • Create a follow-up Task when a Case is created.
  • Send an email when an Opportunity closes.
  • Update the related Account’s total revenue when an Opportunity’s amount changes.
  • Call an external API to sync the record to another system.

The Order Problem

When multiple flows fire on the same event, the order matters.

Salesforce’s order of execution places before-save flows before standard validation rules and after system validation. After-save flows run after all before-save automation, before the triggering record is committed back.

Specifically for record-triggered flows:

  1. System validation (required fields, data types).
  2. Before-save record-triggered flows run.
  3. Validation rules and duplicate rules.
  4. Record saved to database.
  5. After-save record-triggered flows run.
  6. Workflow rules (legacy), process builders (legacy).
  7. After-save flows on parent records in roll-up chains.
  8. Commit.

The practical implication: if a validation rule depends on a calculated value, compute that value in a before-save flow so validation sees the final value.

Trigger Order Within the Same Type

Multiple record-triggered flows on the same object, same timing, same trigger type execute in an undefined order unless you explicitly set trigger order on each.

Set trigger order via the flow’s “Trigger Order” property (1–1000). Smaller numbers run first. Use this when flow A must run before flow B — don’t rely on creation order.

Common Mistake: Recursion

An after-save flow that updates the triggering record causes the record-triggered flow to re-fire. Without guards, this becomes infinite recursion (stopped only by Salesforce’s loop limit, which fails the save loudly).

Prevent with entry conditions:

  • Only run when the relevant field actually changed (ISCHANGED check via Run Immediately When Changed).
  • Use a hidden “Suppress Automation” checkbox set by the flow itself to break recursion for updates originating from automation.

Before-save flows updating the triggering record do not re-fire — that’s one more reason before-save is the cheaper choice when you can use it.

Performance Implications at Scale

A before-save flow that updates 10 fields on a record costs zero extra DML. An after-save flow that does the same work consumes one DML per record.

In a bulk DML operation processing 200 records, that’s 200 DMLs just for automation updates — meaningfully closer to the 150-DML-per-transaction limit (the limit is per transaction, not per record). You will feel this when users run data loader jobs.

Migration Notes

If you inherited an org full of after-save flows doing simple field updates, they’re candidates for conversion to before-save. The savings compound as volume grows.

Before migrating:

  1. Verify the flow only updates the triggering record (no cross-object writes).
  2. Check entry conditions and fault handling.
  3. Deploy to sandbox and run a bulk test load.
  4. Monitor the debug log for unexpected downstream effects.

Decision Checklist

Before creating a new record-triggered flow, answer these in order:

  • Does the flow modify only the triggering record? → Before-save.
  • Does the flow need to read related records? → After-save (or before-save with Get Records).
  • Does the flow create or update other records? → After-save.
  • Does the flow make a callout? → After-save (and consider async paths for callouts that can be deferred).
  • Does the flow send communications? → After-save.

Frequently Asked Questions

Can a before-save flow call Apex?

It can invoke invocable Apex methods, but the Apex cannot perform DML. Use invocable Apex in before-save only for pure computation.

Can I have both a before-save and an after-save flow on the same object?

Yes, and it’s a common pattern. Before-save handles field computation; after-save handles side effects.

What happens if a before-save flow fails?

The save fails and the user sees an error. Design fault handling carefully — before-save faults block record creation.

Are triggers better than flows for complex logic?

For deeply complex logic or high-volume bulk operations, Apex triggers give finer control. For the majority of transactional automation, flows are easier to maintain and perform well enough.

Share