Salesforce Order of Execution
In Salesforce, understanding the Order of Execution is crucial for developers, administrators, and anyone looking to ensure that their workflows and automation processes run smoothly. The Order of Execution outlines the sequence of operations Salesforce follows when creating, updating, or deleting a record, ensuring proper interaction between business rules and processes with the data.
When a record is saved, Salesforce executes several operations behind the scenes, from validation rules to triggers, and all these happen in a very specific order. This order ensures consistency, prevents conflicts, and allows Salesforce to maintain data integrity.
1. Load the Original Record
Before any operation takes place, Salesforce loads the record data into memory. This involves collecting all field values, and determining whether the operation is for create, update, or delete.
2. Identify the Request
Salesforce determines the origin of the request, which could be from standard UI pages, custom UI pages, SOAP API, or REST API. Depending on the request’s source, Salesforce conducts various validation checks.
3. Execute Before Save Record Triggered Flows
Execute record-triggered flows that are configured to run before the record is saved.
4. Before Triggers (Before Insert, Before Update)
Before triggers are fired after the data is loaded but before any changes are made to the database. This is where you can perform validation, modify field values, or prevent changes before they reach the database.
For example, if you want to validate business logic or make field adjustments before Salesforce saves the record, you do this in these triggers.
5. Validation Rules
Salesforce then checks if the record adheres to any validation rules. These rules ensure that the data entered into the fields meets specific criteria (e.g., preventing the user from entering an invalid email address or phone number).
If any validation rule fails, the process stops here, and an error message is displayed.
6. Duplicate Rules
Salesforce performs checks against any duplicate rules to ensure that the new record does not conflict with existing records. If a conflict is found, it can either block the save or flag the record as a potential duplicate.
The duplicate rule helps prevent creating multiple records with the same data (e.g., two contacts with the same email address).
7. Save the Record
After the duplicate rules, Salesforce will save the record but not commit it to the database. The record will only be committed once it successfully completes the entire order of execution without any errors.
8. After Triggers (After Insert, After Update)
After triggers are executed after the record has been committed to the database but before the transaction is finalized. This is a great place to perform operations like sending emails, making HTTP callouts, or creating child records in related objects.
After triggers can access the record’s ID (which was assigned during the database commit) and can also update related records.
9. Assignment Rules
Assignment rules are executed after the record has been saved to the database. These rules automatically assign records to specific users or queues based on certain criteria.
Typically used for lead and case assignments, these rules ensure that records are routed to the appropriate people for follow-up.
10. Auto-Response Rules
Auto-response rules come into play for objects like Leads and Cases. They send automatic email responses based on the criteria specified in the rule.
For example, if a lead is created, an auto-response email can be sent to the person who created the lead, acknowledging the submission.
11. Workflow Rules
Workflow rules are fired next. A workflow rule can trigger actions like field updates, sending outbound messages, or initiating email alerts.
Workflow actions are queued and executed based on the rule conditions that evaluate data after the record is saved.
12. Escalations Rules
Escalation rules are typically applied in Service Cloud to escalate cases based on conditions, such as a case not being resolved within a specified timeframe.
These rules ensure that cases are handled in a timely manner and bring attention to issues that are not being addressed promptly.
13. Execute Flow Automations
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
14. Execute After Save Record Triggered Flows
If a Flow is designed to be triggered after a record is saved (after save flow), it will run at this stage. Flows can carry out more advanced logic and updates, including user interaction through screen flows or additional record creation/modifications.
They are more powerful than workflows or process builder, offering a drag-and-drop approach to automation.
15. Execute entitlement rules
If the record is an object that supports Entitlement Rules, Salesforce executes the Entitlement Rules at this stage.
These rules ensure that customers receive the appropriate level of service based on their entitlements, such as response and resolution times, by automatically applying them to cases, ensuring consistent and efficient service delivery.
16. Roll-Up Summary on Parent
If there are any roll-up summary fields, Salesforce will calculate these based on related records at this stage. This includes aggregating data like sums, averages, or the most recent value.
This calculation takes place after the record is saved and triggers updates on the parent record.
17. Roll-Up Summary on Grandparent
When the parent record is updated, and the grandparent record includes a roll-up summary field or is involved in a cross-object workflow, the calculations are performed, and the roll-up summary field in the grandparent record is updated. The grandparent record then undergoes the save process.
18. Criteria-Based Sharing Rules
At this stage, Salesforce evaluates and applies all Criteria-Based Sharing Rules to the relevant records, ensuring proper sharing.
These rules enable you to automatically share records with selected users, groups, or roles when certain field values or conditions are met, ensuring the right people have access to the right data.
19. Final Commit to Database
At this point, all operations are complete, and the transaction is committed to the database. The record is now fully saved and can be accessed by users and processes.
If there are no errors throughout the process, the record is saved successfully.
20. Post-Commit Logic
Post-commit logic is the final step after the transaction is committed to the database. This includes sending outbound messages (emails etc), calling external services via HTTP callouts, or invoking other external systems.
Outbound messages are typically used in integration scenarios where data needs to be sent to another system.
Conclusion
Understanding Salesforce’s Order of Execution is vital for developers and administrators when designing solutions, as it helps to control and optimize the automation, validation, and business logic applied to records. By knowing the exact sequence in which Salesforce applies different processes, you can avoid errors, ensure smoother automation, and better troubleshoot issues in your Salesforce org. Always consider how different automation features work together, and design your solutions accordingly to maximize their efficiency and impact.
