Solutions DeliveredSolutions Delivered SkillsSkills ArticlesArticles AboutAbout ContactContact
Download Resume

Making Sense of the Salesforce Save: A Collaborative Guide to the Order of Execution

Published on: July 20, 2025

For those of us who work with Salesforce as administrators or developers, a deep understanding of the Order of Execution is a fundamental requirement for success. It’s the precise, non-negotiable sequence of operations that Salesforce performs every time a record is saved. This sequence governs how all our automations, validations, triggers, and rules interact. Mastering it is the key to building predictable applications, debugging complex issues, and preventing unintended consequences like recursive loops.

Whenever a record is saved, it embarks on an intricate journey through a series of distinct steps before the change is permanently written to the database. To make this complex process easier to understand, we can use some simple analogies alongside the technical details. We can logically categorize this journey into four main stages.

Phase 1: Before Save & Validation

Validation & Preparation

Includes initializing the record, running system validations, Before-Save Flows, before Apex triggers, Custom Validation Rules, and Duplicate Rules. Any failure here stops the process.

Phase 2: After Save Automation

Automation & Related Record Updates

After the initial uncommitted save (Step 7), Salesforce runs after Apex triggers, Assignment/Auto-Response/Workflow/Escalation/Entitlement Rules, Processes, After-Save Flows, and calculates Roll-Up Summaries.

Phase 3: Final Commit

Commit to Database

All changes are permanently saved to the database and become visible to all users. This is the point of no return.

Phase 4: Post-Commit Activities

Asynchronous Actions

Actions that should only happen after a successful save are performed, such as sending emails and enqueuing asynchronous jobs.

A Deeper Dive into the Phases
To better understand what happens at each stage of the save process, let's break down the key steps within each phase:

Phase 1: Before the Record is Saved

We can think of this initial phase like a chef preparing all the ingredients before starting to cook. The focus here is on preparing the record and rigorously validating its data before it's allowed to be saved, ensuring data integrity from the outset.

  1. Initialize Record: First, Salesforce gets its "workstation" ready. For an update, it loads the original record data from the database. For a new record insertion, it initializes an empty record object in memory to hold the forthcoming data.
  2. Load New Record Data & Run Initial System Validations: The new values submitted by the user or an external system are loaded into the record. At this moment, the system runs its most basic validations, which include:
    • Checking for required values at the page layout level (when a record is saved through the standard UI).
    • Verifying required values at the field-definition level.
    • Ensuring valid field formats and that maximum field lengths are not exceeded.
    • Validating foreign keys and ensuring values for restricted picklists are correct (these checks are particularly important for API data loads).
  3. Execute Before-Save Record-Triggered Flows: Next, any record-triggered flows configured for "Fast Field Updates" will execute. These are the most efficient and recommended tool for making changes to the fields on the record we're currently processing, as they run before most other automations.
  4. Execute before Apex Triggers: Any custom Apex code contained within before triggers (before insert or before update events) runs next. This step provides developers with an opportunity to write custom code that can perform complex validations or programmatically modify the record's fields.
  5. Run System and Custom Validations Again: Salesforce intentionally runs most system validations a second time. This is critical because the preceding flows and before triggers may have modified data. This second check ensures those changes still comply with system integrity. Following this, all active custom Validation Rules created by administrators in Setup are checked. If any validation rule formula evaluates to true, an error message is displayed, and the entire save process is halted. In our kitchen analogy, this is like the head chef doing a final quality check on the prepped ingredients before they go into the pan.
  6. Execute Duplicate Rules: The system now runs Duplicate Rules to prevent the creation of redundant records. This is a two-part process: a Matching Rule first defines how to identify a potential duplicate, and then the Duplicate Rule takes action, which can either block the save or allow it with a customizable alert.

Phase 2: The Initial Save and "After" Automation

With the data validated, Salesforce performs the initial save and then executes the bulk of its automation tools.

  1. Save the Record (But Do Not Commit): The record is saved to the database, but the transaction is not yet made permanent, or "committed." For a new record, this is the critical point where its unique 18-character Record ID is generated. This saved, uncommitted data is only visible within the current transaction. This step is like getting a ticket number for an order. The order is officially in the system and has a unique identifier (the Record ID), but the final product hasn't been delivered yet. This ID is crucial, as it allows all subsequent automations to refer to this specific record.
  2. Execute after Apex Triggers: The after Apex triggers (after insert or after update) are now executed. This is the first point in the order where developers can reliably access the record's new ID, which is why actions on different, related records are typically performed here.
  3. Run Assignment Rules: For Lead and Case objects, specific Assignment Rules are executed to automatically assign ownership to the appropriate user or queue.
  4. Run Auto-Response Rules: Also specific to Lead and Case objects, Auto-Response Rules execute to send an automatic email response to the customer who submitted the record.
  5. Execute Workflow Rules: The system executes any active legacy Workflow Rules. If a Workflow Rule updates a field on the current record, it can trigger a partial re-execution of the save order, including before and after update triggers and system validations.
  6. Execute Escalation Rules: For the Case object, time-dependent Escalation Rules run to automatically escalate a case if it has not been resolved within a predefined time frame.
  7. Execute Processes from Process Builder: Processes built with the now-retired Process Builder tool are executed.
  8. Execute After-Save Record-Triggered Flows: Record-triggered flows designed for "Actions and Related Records" are executed. These are the modern, preferred declarative tool for handling complex automation logic and interacting with related records.
  9. Run Entitlement Rules: Entitlement Rules are executed to apply specific customer service levels and milestones to records like cases.
  10. Calculate and Update Roll-Up Summary Fields: If the record is a child in a master-detail relationship, any Roll-Up Summary Fields on the parent record are calculated. This update causes the parent record to go through its own complete save cycle, from the very first step. This can create a cascading domino effect, where the parent record's update triggers its own chain reaction of automations, and could even impact grandparent records further up the hierarchy.
  11. Evaluate Criteria-Based Sharing Rules: The system evaluates all Criteria-Based Sharing Rules to grant or revoke access to records based on the final data in their fields.

Phase 3: The Final Commit

The transaction is finalized and made permanent.

  1. Commit All DML Operations: If every preceding step has been completed successfully, all the changes are now permanently committed to the database. We can think of this as the moment we switch from writing in pencil to using permanent ink. The changes are now official, irreversible, and visible to all other users and transactions. If any critical error had occurred, the entire transaction would have been rolled back, and no changes would have been saved.

Phase 4: Post-Commit Activities

These final actions are intentionally performed only after the data has been successfully and permanently saved. This ensures that irreversible actions, like sending an email, don't happen if the core transaction ultimately fails.

  1. Execute Post-Commit Logic: This final stage includes operations that should only happen after a successful database commit. These actions include:
    • Sending emails, such as email alerts triggered by flows or other automations.
    • Enqueuing asynchronous Apex jobs, which involves placing @future methods, Queueable Apex, and Batch Apex jobs into the execution queue.
    • Running asynchronous paths in Record-Triggered Flows, where any part of a flow designated to run asynchronously after the main transaction is initiated.

By understanding this precise order, we can design automations that work in harmony, troubleshoot issues effectively, and build robust, scalable solutions on the Salesforce platform.

About the Author

This article was written by Ashay Taksande.

Salesforce Certified Administrator Badge