Before-Save vs After-Save Record-Triggered Flows in Salesforce — Key Differences & Best Practices

Posted by Vinay Vernekar 17th December 2025

What are Record-Triggered Flows?

Record-Triggered Flows in Salesforce automate logic that runs when a record is created or updated. Salesforce provides two primary types of record-triggered automation: before-save flows (fast field updates) and after-save flows (actions after the record is committed). Understanding when to use each is essential for performance, correctness, and staying within Salesforce limits.

Core Differences: Before-Save vs After-Save

1) When they run

Before-save flows run during the save transaction before the database commit. They execute quickly and can modify field values on the triggering record without performing an extra DML operation. After-save flows run after the record is saved and committed to the database.

2) Primary use-cases

Use Before-Save Flows to:

  • Update fields on the triggering record efficiently (fast field updates).
  • Implement formula-like calculations or defaulting logic that must be applied before validations and workflows.

Use After-Save Flows to:

  • Create, update, or delete related records.
  • Call external systems via actions or platform events.
  • Send email alerts, post to Chatter, or invoke invocable Apex/subflows.
  • Work with the record Id (available after save) if needed by downstream operations.

3) DML and Performance

Before-save flows are optimized for performance: they update the triggering record in-memory and participate in the same save operation, avoiding an extra DML call. After-save flows may perform additional DML (e.g., create related records), which counts against governor limits and can affect transaction performance.

4) Access to Record Id and Related Data

After-save flows have access to the record Id and can reliably query or act on related records that depend on the saved Id. Before-save flows run before the Id is guaranteed for certain operations and are therefore not suitable when downstream actions require the persisted record Id.

5) Order of Execution and Interaction with Other Automation

Before-save flows execute early in the save lifecycle and influence subsequent validation rules, workflows, and after-save automation. After-save flows execute later and can trigger other automations (for example, creating a related record can in turn invoke other record-triggered flows).

Practical Examples

Before-Save Example

Scenario: When an Account is updated, normalize the Account name (trim whitespace, set proper case) and set a flag if certain keywords are present. These changes only affect the Account fields.

// Pseudocode: Before-Save Flow
if (Account.Name != null) {
Account.Name = trimAndTitleCase(Account.Name);
Account.Requires_Follow_Up__c = containsKeyword(Account.Name, 'Important');
}

After-Save Example

Scenario: After an Opportunity is closed-won, create a related onboarding Task, send a welcome email, and call an external onboarding system. These actions require the Opportunity Id and involve creating related records and external calls.

// Pseudocode: After-Save Flow
if (Opportunity.StageName == 'Closed Won' && !alreadyProcessed) {
create Task (WhatId = Opportunity.Id, Subject = 'Onboarding');
sendEmailTemplate(opportunityOwner, templateId);
callExternalService(opportunityData);
}

Best Practices

  • Prefer Before-Save flows for simple field updates on the same record for better performance.
  • Use After-Save flows for actions that require the record Id, create/update related records, or call external services.
  • Keep flows modular: use subflows and invocable actions when logic is reused across automations.
  • Monitor limits — after-save flows can consume SOQL/DML limits; design for bulk behavior and bulkify actions.
  • Test both happy and bulk paths using Flow Builder debug and by running bulk data operations in a sandbox.

Quick Comparison (at a glance)

Before-Save: fast field updates, runs in same save transaction, does not consume extra DML for the triggering record, ideal for field calculations.

After-Save: runs after commit, suitable for related records, external calls, emails, and actions requiring record Id.

Conclusion

Choose Before-Save Record-Triggered Flows when you need lightweight, performant field updates on the triggering record. Choose After-Save Record-Triggered Flows when your logic needs the saved record Id, must create or modify related records, or integrate with external systems. Applying the right type of flow improves performance, avoids unnecessary DML, and reduces the risk of hitting governor limits.