We can’t deny that Flow Builder has become the go-to tool for automating business processes. As good old Process Builder and Workflow Rules take a backseat, understanding the different types of flows has become more important in building effective and efficient automation. One of the commonly used flows we have today is the record-triggered flow.
In this article, we’ll break down two types of record-triggered flows: before-save and after-save. We’ll take a deep dive into what each type means, when to use them, and how they behave differently depending on your automation goals.
Understanding Record-Triggered Flows
The simplest way to explain record-triggered flows is to emphasize that they are designed to execute automatically when a record is created, updated, or deleted. They let you simplify processes without having to write any code.
The power of record-triggered flows lies in their ability to automate tasks that would otherwise require manual intervention. For example, you can set up a record-triggered flow that runs whenever a new Opportunity is created.
Upon creation, the flow can automatically assign tasks, send notifications, or update related records all on its own, ensuring consistency and efficiency across the org by minimizing user input.
However, there is a key decision point that comes in pretty early in the flow creation process for record-triggered flows. This decision influences a critical aspect of your flow’s behavior: the timing of its execution relative to the record’s save operation.
I like to compare before-save flows to a smartphone keyboard’s autocomplete or autocorrect feature. With the large number of autocorrect memes on the internet, it’s clear that this feature can be hilariously overzealous (changing “meet” to “meat” at the worst possible moment).
Yet most of the time, it quietly corrects typos or predicts our intent, inserting words as you type rather than waiting for you to finish your message and then suggesting corrections. When it works as intended, it can save you from manual fixes and speed up your typing.
Like how autocorrect can save you from sending over a message with a typo, before-save flows are optimized for making quick updates to the record that triggered the flow, such as setting default values or performing simple calculations. As they run before the save operation, they can enhance performance by reducing the number of database operations or updates required.
Under the hood, these flows can run up to ten times faster than other record-change processes, since they avoid an extra save cycle and don’t count against DML limits when updating the triggering record.
This cut on DML statements can be significant in large and complex orgs, as before‑save flows can help you stay comfortably within governor limits, all while ensuring data quality and consistency.
After-Save Flows
Now these are pretty common, as after‑save record‑triggered flows fire after Salesforce commits a record to the database. This means full access to the record’s ID and any related data is granted and exists before doing any of the updates or actions that the flow dictates. In Flow Builder, Actions and Related Records indicated an After Save flow.
You can do a wide variety of actions with after-save flows – from creating or updating related records to sending email alerts, and even posting to Chatter or invoking asynchronous paths/external services!
Because they run post‑save, every update to the triggering record requires explicit DML, as opposed to Before-Save flows. This counts against governor limits and can add slight performance overhead if not designed carefully, so keep that in mind and do your best to keep these flows efficient! It’s best practice to filter your entry criteria and offload non‑urgent work to scheduled or asynchronous paths.
When Should You Use Before-Save or After-Save Flows?
When determining which record-triggered flow type to use, the first thing to consider is whether your automation solely updates the triggering record or needs to perform actions on related objects or external systems.
Before-save flows run in a pre-commit context to deliver super-fast, in-memory field updates, while after-save flows fire post-commit, which means they can leverage the record’s ID and execute from a rich palette of subsequent actions.
When to Use Before-Save Flows
- Fast Field Updates: Choose before-save flows when your logic only needs to modify fields on the record that triggered the flow, without interacting with related records or invoking email alerts.
- Performance-Critical Scenarios: Before-save flows execute before the commit and avoid an extra DML operation, often running up to ten times faster than after-save flows.
One common use case example is auto-populating or normalizing fields, such as stamping a “Last Reviewed” date, or enforcing uppercase in important text fields, or auto-calculating a “Lead Score”.
When to Use After-Save Flows
One of the main benefits of this kind of flow is full record context. It technically has access to the triggering record’s ID and any related data, letting you build or link child records seamlessly and without the need for workarounds.
- Full Record Context Needed: Go for after-save flows when your logic depends on the record’s Salesforce Id or must work with related objects, such as creating child records or updating fields on other related records.
- Wide Variety of Actions: After-save flows support Create Records, Send Email, Post to Chatter, Launch Subflows, and more.
Here’s a sample use case: when a new Case is created, send a welcome email to the Contact, generate a follow-up Task for the Owner, and update a Support Metrics record. Notice that these tasks require the triggering Case Id and call for cross-object updates, all of which are best handled in an after-save flow.
Before-Save vs After-Save at a Glance
| Feature / Action | Before-Save | After-Save |
|---|---|---|
| Runs on Create | ✅ | ✅ |
| Runs on Update | ✅ | ✅ |
| Runs on Delete | ❌ | ✅ |
| Update Triggering Record | ✅ (no extra DML) | ✅ (explicit DML) |
| Create New Records | ❌ | ✅ |
| Delete Records | ❌ | ✅ |
| Update Related Records | ❌ | ✅ |
| Access Record ID | ❌ | ✅ |
| Send Email Alerts | ❌ | ✅ |
| Post to Chatter | ❌ | ✅ |
| Submit for Approval | ❌ | ✅ |
| Invoke Apex Actions | ❌ | ✅ |
| Publish Platform Events | ❌ | ✅ |
| Call Subflows | ❌ | ✅ |
| Performance | 🔥 Very fast, in-memory updates | ⚡ Full context but extra DML |
| Typical Use Case | Auto-populate or normalize fields | Multi-object orchestration, notifications, related record updates |
Final Thoughts
In the end, choosing between a before-save or after-save record-triggered flow comes down to one simple question: Do you only need to tweak fields on the record itself, or do you need the full power of the record’s ID and related-object actions?
If your goal is super-fast, in-memory updates like normalizing data or stamping audit fields, before-save flows are your go-to. But when your business logic requires creating child records, firing emails or notifications, or integrating with other systems, after-save flows will give you the full context and capability you need.
By weighing performance considerations (DML, governor limits) against functional requirements (access to the record ID, related-record actions), you can confidently select the right flow type for every automation scenario and build better, scalable processes in your Salesforce org.