Before-Save vs After-Save Flows in Salesforce: Key Differences Explained
Introduction
Salesforce Flow is a powerful automation tool that allows administrators and developers to automate business processes without writing code. Among the different types of flows, Before-Save and After-Save flows are commonly used for record-triggered automation. Understanding the differences between these two is crucial for designing efficient and effective automations.
Table of Contents
1. What Are Before-Save and After-Save Flows?
Before-Save Flows
Before-Save flows execute before a record is saved to the database. They run in the same transaction as the save operation, meaning any changes made in the flow are part of the initial save.
Key Characteristics:
- Execute before the record is committed to the database.
- Operate in memory, meaning they don’t require a DML operation.
- Ideal for field updates, validations, and default values.
- Faster execution since they avoid additional database operations.
After-Save Flows
After-save flows execute after a record is saved to the database. They run in a separate transaction and can perform actions that require the record to already exist in the database.
Key Characteristics:
- Execute after the record is saved.
- Can perform DML operations (create, update, delete related records).
- Suitable for complex automations, updates to related records, and async processes.
- May introduce slight delays due to additional database operations.
2. Key Differences Between Before-Save and After-Save Flows
3. When to Use Before-Save vs After-Save Flows?
Use Before-Save Flows When:
✅ You need to modify field values before saving (e.g., auto-calculating a field).
✅ You want to validate data before saving (e.g., preventing invalid entries).
✅ Performance is critical (since it avoids additional DML operations).
✅ You don’t need the record ID (because it hasn’t been saved yet).
Example:
- Automatically setting a priority field based on certain criteria.
- Preventing a record from saving if a required field is blank.
Use After-Save Flows When:
✅ You need the record ID (e.g., to create related records).
✅ You must update or create related records (e.g., creating a task after saving a lead).
✅ You need to call external systems (e.g., making an API call after record creation).
✅ You require async processing (e.g., sending an email after a record is saved).
Example:
- Creating a follow-up task when an opportunity reaches a certain stage.
- Updating a related account record after a contact is created.
4. Best Practices for Using Before-Save and After-Save Flows
For before-save flows:
✔ Keep logic simple – Avoid complex operations since they run in the same transaction.
✔ Use for real-time validations – Ensure data integrity before saving.
✔ Avoid queries – Since the record isn’t saved yet, queries may not be necessary.
For After-Save Flows:
✔ Optimize DML operations – Batch updates to avoid hitting governor limits.
✔ Handle errors gracefully – Use fault paths for error handling in async flows.
✔ Consider recursion – Ensure flows don’t trigger themselves in an infinite loop.
5. Common Pitfalls and How to Avoid Them
Before-Save Flow Pitfalls:
❌ Trying to access related records – Since the record isn’t saved, you can’t query related data.
❌ Overcomplicating logic – Complex operations may slow down record saving.
Solution: Move complex logic to After-Save flows if needed.
After-Save Flow Pitfalls:
❌ Unoptimized DML operations – Too many updates can hit governor limits.
❌ Recursive triggers – Flows that update the same record can cause loops.
Solution: Use entry conditions and static variables to prevent recursion.
6. Real-World Examples
Before-Save Flow Example:
Scenario: Auto-populate a discount percentage field on an opportunity based on the amount.
Steps:
- Trigger: When an opportunity is created or updated.
- Condition: If Amount > $10,000, set Discount to 10%.
- No DML needed—changes apply before save.
After-Save Flow Example:
Scenario: Create a task when a case is marked as “escalated.”
Steps:
- Trigger: When a case is updated.
- Condition: If Status = “Escalated,” create a task for the case owner.
- Requires DML since the task is a separate record.
7. My Takeaway: Before-Save vs After-Save Flows in Salesforce
The differences between Before-Save and After-Save Flows is crucial for building efficient and optimized Salesforce automation. Use Before-Save Flows for fast, simple updates without triggering additional processes, and After-Save Flows for more complex logic involving related records, actions, or external calls. Choosing the right flow type ensures better performance, data integrity, and scalability within your Salesforce org. Mastering both empowers admins and developers to automate effectively.