Building solutions with Salesforce is a fairly easy task, but if you do not go below the surface, your solutions may end up creating unintended technical debt in your system. This can slow down your org, or worse yet: you may start finding fatal errors due to exceeding limits.
When you save a record, it goes through a specific sequence of events which is the Salesforce Order of Execution. This article reviews:
- Reference diagram with detailed steps.
- Full list of from the Developer Docs.
- Key considerations from Order of Execution and Flow Behavior before and after Spring ’22.
Salesforce Order of Execution
Declarative, low code, and code solutions are all woven into the Order of Execution and affect how your system runs. Whether you are an admin, developer, or architect, always keep in mind how your new solution is affecting and interacting with the existing org standard functionality, managed packages, and existing customizations.
Order of Execution from Developer Docs API v54
The following are the steps that occur on the server when you save a record. Don’t worry, you do not need to memorize the list! Instead, use the diagram above for reference:
- Load the original record from the database or initialize the record for an upsert statement.
- Load the new record field values from the request and overwrite the old values.
- If the request came from a standard UI edit page, Salesforce runs system validation to check the record for:
- Compliance with layout-specific rules
- Required values at the layout level and field-definition level
- Valid field formats
- Maximum field length
- When the request comes from other sources, such as an Apex application or a SOAP API call, Salesforce validates only the foreign keys. Before executing a trigger, it verifies that any custom foreign keys don’t refer to the object itself.
- Salesforce runs custom validation rules if multiline items were created, such as quote line items and opportunity line items
- If the request came from a standard UI edit page, Salesforce runs system validation to check the record for:
- Execute record-triggered flows that are configured to run before the record is saved.
- Execute all before triggers.
- Run most system validation steps again, such as verifying that all required fields have a non-null value and runs any custom validation rules. The only system validation that Salesforce doesn’t run a second time (when the request comes from a standard UI edit page) is the enforcement of layout-specific rules.
- Execute duplicate rules. If the duplicate rule identifies the record as a duplicate and uses the block action, the record isn’t saved and no further steps (such as after triggers and workflow rules) are taken.
- Save the record to the database but don’t commit just yet.
- Execute all after-triggers.
- Execute assignment rules.
- Execute auto-response rules.
- Execute workflow rules. If there are workflow field updates:
- Update the record again.
- Run system validations again. Custom validation rules, flows, duplicate rules, processes, and escalation rules aren’t run again.
- Execute before update triggers and after update triggers, regardless of the record operation (insert or update), one more time (and only one more time).
- Execute escalation rules.
- Execute the following Salesforce Flow automations, but not in a guaranteed order.
- Processes
- Flows launched by processes
- Flows launched by workflow rules (flow trigger workflow actions pilot)
- When a process or flow executes a DML operation, the affected record goes through the save procedure.
- Execute record-triggered flows that are configured to run after the record is saved.
- Execute entitlement rules.
- If the record contains a roll-up summary field or is part of a cross-object workflow, perform calculations and updates the roll-up summary field in the parent record. Parent record goes through a save procedure.
- If the parent record is updated, and a grandparent record contains a roll-up summary field or is part of a cross-object workflow, perform calculations and update the roll-up summary field in the grandparent record. Grandparent record then goes through save procedure.
- Execute Criteria Based Sharing evaluation.
- Commit all DML operations to the database.
- After the changes are committed to the database, execute post-commit logic are executed.
- Examples of post-commit logic (in no particular order) include:
- Sending an email
- Enqueued asynchronous Apex jobs, including queueable jobs and future methods
- Asynchronous paths in record-triggered flows
- Examples of post-commit logic (in no particular order) include:
Important Considerations and Changes from Flow Behavior
In recent releases, the biggest change to the Order of Execution in Salesforce has been the introduction of flows. These are the important considerations and changes announced in the Spring ’22 Release.
- Validation:
- System validation checks for values in required fields, field type, length validation, etc.
- If the record is updated in the UI, system validation includes page layout-specific settings for Edit/Read-only fields.
- All active validation rules are evaluated for all record saves.
- Custom validation rules and dup rules only run one time.
- After Triggers, Assignment & Auto-Response Rules Execute:
- Records are further updated per the custom code logic.
- Assignment rules update the record owner per the first rule that matches your record.
- Assignment Rules run on creation or if they are called via apex to be rerun on record updates.
- Auto-Response Rules run on record creation and prepare the email to be sent per the first rule that matches your record.
- If you have multiple triggers per object, you cannot set the order in which they fire.
- Workflow Rules, Approval Processes, and Process Builders Run (Potential Loop Time!):
- All active workflow rules are evaluated for all record saves.
- Approvals are treated as workflows.
- For Workflow Rules, field updates are executed before all other actions.
- All active Process Builders are evaluated for all record saves.
- For all field updates that cause re-evaluation, all WFR/AP/PB that did not run one time are re-evaluated up to 5 additional times.
- Each Workflow rule and Process builder field updates records causes System Validation, Before Triggers, and After Triggers to run for each cycle.
- Like triggers, for WFR/AP/PBs, you cannot set the order in which they run.
- Before Save & After Save Flows:
- Before Save Flows are run right after system validation.
- Flows are executed only one time per entity, per transaction.
- Only Flows with matching entry criteria run for record saves.
- Set Running Order for the same object.
- Flows of the same type runs in the order specified in the flow:
- Runs flows ordered 1-1000 first
- Then unordered flows
- Then flows ordered 1001-2000
- API 54 Changes to Flows:
- Time-Based Field Updates are a separate transaction and run flows only.
- Run before Entitlement Rules, so that entitlements can include the record updates that after-safe flows make.
- Omni Routing:
- When work is routed and assigned, triggers, workflow rules, approval processes, and escalation rules do not run.
- Once the record is edited and saved again, the standard operations run.
Summary
In most orgs, you will end up with clicks with code so use the Salesforce Order of Execution to your advantage. Maximize the success of your solutions and your system with these key takeaways:
- The Order of Execution affects every saved record on the UI or via API.
- The order may be different based on the API of your components.
- Stay up to date with each release to see any changes made.
Share this information with your full Salesforce team including BAs, admins, developers, testers, and architects!
Comments: