Understanding Record-Triggered Flows in Salesforce

In Salesforce, a Record-Triggered Flow is an automated process that executes when a record for a standard or custom object is created, updated, or deleted. These flows allow developers and admins to automate complex business logic "behind the scenes" without requiring direct user interaction or custom Apex code.

A screenshot of the Salesforce Flow configuration window showing the 'Select Type and Optimization' section. Two options are visible: 'Fast Field Updates' (highlighted as the performant choice for before-save updates) and 'Actions and Related Records' (the default choice for after-save logic and related object updates).
Salesforce Flow configuration screen illustrating the selection between 'Fast Field Updates' (Before-Save) and 'Actions and Related Records' (After-Save). Note that the latter is selected by default.

Types of Record-Triggered Flows

Record-triggered flows are categorized into two primary types based on their execution timing: Before-Save and After-Save.

  • Before-Save Record-Triggered Flows (Fast Field Updates)

    Before-save flows are designed specifically to update fields on the record that triggered the automation. Because these updates occur before the record is committed to the database, they are significantly faster — often up to 10 times more efficient — than after-save updates.

    • Best For: Setting default values, data normalization (e.g., forcing uppercase), and field validation.
    • Performance: These are highly optimized as they avoid additional DML (Data Manipulation Language) operations and do not re-trigger the entire Save execution order.

  • After-Save Record-Triggered Flows (Actions and Related Records)

    After-save flows execute after the record has been initially saved to the database but before the transaction is fully committed. Because the record already exists in the database at this stage, its Record ID is available for use.

    • Best For: Creating or updating related (child) records, sending email alerts, and performing asynchronous tasks.
    • Extensibility: These flows support HTTP Callouts via asynchronous paths, making them the standard choice for external API integrations.

Decision Framework: Which Flow Should You Use?

Choosing the correct flow type is essential for maintaining a scalable and high-performing Salesforce environment.

Use Before-Save Flows When:

  • Logic is local: You only need to modify fields on the triggering record itself.
  • Performance is a priority: You want to minimize the impact on Salesforce governor limits and avoid unnecessary recursion.

Use After-Save Flows When:

  • Record ID is required: You need the unique Salesforce ID to link new child records.
  • Interacting with others: You need to create or update related objects (e.g., creating a Task when an Account is updated).

  • External Actions: You need to trigger notifications or outbound integrations.

    Common Pitfall: A frequent mistake is using an After-Save flow to perform simple field updates on the triggering record. For example, converting an Account Name to uppercase is technically possible in an After-Save flow, but it is far less efficient. Using a Before-Save flow for this task ensures the data is corrected before it ever hits the database, saving system resources.

Summary and Best Practices

The choice between Before-Save and After-Save flows ultimately depends on whether your automation is self-contained or relational.

  • Before-Save is your "go-to" for data integrity and speed.
  • After-Save is your powerhouse for cross-object logic and integrations.

To build robust and scalable automations, always weigh your functional requirements (child records, ID availability) against system considerations (governor limits, recursion, and the Salesforce Order of Execution).