In this blog post, we will understand the concept of Salesforce’s Order of Execution and why it is important in the Salesforce ecosystem.
What is the Order of Execution of Salesforce?
Whenever you create or modify a record in Salesforce, a set of events, called the Order of Execution, starts work. This sequence checks and governs all the interactions between different automation and functionalities as they affect the record, starting from the moment you click save until the changes are finalized.
Salesforce as a multi-tenant architecture:
Salesforce architecture is quite popular due to its multitenancy. Many customers use the same server configuration that makes it cost-effective but their data is safely separate, which means each client’s information remains protected and separate from other clients.
Multi-tenancy enables any developer to create an application, host it to the cloud, and quickly share it with many clients. In addition, the developers can update the offered software in a single location and all users of the application will receive the latest version.
Salesforce ensures that each organization’s operations are carried out without interference from others and within the allocated resource limits. Salesforce’s multitenant architecture stores all client data in a single database. In terms of governor limits, Salesforce’s multi-tenant architecture helps enforce these limits by ensuring fair resource allocation among all organizations.
Flow of Execution
Load & Prepare Data:
Salesforce retrieves the original record (update) or initializes a new one (upsert). New field values overwrite existing ones.
Standard Validations (UI Edits Only):
The system checks for layout rules, required fields, valid formats, and maximum field lengths (applicable only for edits from the standard UI). For other sources like APIs and Apex, only foreign keys are validated.
App Initialization:
Application initialization involves gathering all the necessary information about how things should work for your specific task. It loads the metadata, which acts like a blueprint, and configuration settings that define how the application should function in this situation.
Custom Validations:
Salesforce executes any custom validation rules that you’ve defined.
Record-triggered flows (before save)
Record-triggered flows can run at two specific points in the Salesforce record save process i.e Before Save and After save.
Before Triggers:
When you write custom Apex code, it executes before the record is saved. This provides an opportunity for manipulating data or conducting pre-save validations.
Validations & Duplicate Rules:
Standard validations (except layout rules for UI edits) run again. Salesforce actively checks for duplicate records using defined rules, if a duplicate is found and the “block” action is set, the system prevents the record from being saved.
Save (Uncommitted):
Salesforce saves the modified record to the database temporarily, not permanently.
After Triggers:
After saving the record, Salesforce triggers your custom Apex code, allowing for post-save actions.
Assignment & Auto- Response Rules:
Assignment rules assign the record to the appropriate owner. Auto-response rules trigger actions like sending emails based on record changes. Workflow rules execute field updates, notifications, or other actions based on defined criteria.
Workflow Field Updates (if applicable):
If workflow rules update fields, the record is saved again. Before and after update triggers fire one more time (only once) for these updates. Custom validations, duplicate checks, and escalation rules are not repeated.
Escalation & Entitlement Rules:
Escalation rules can be triggered based on record changes. Entitlement rules may also execute (depending on your setup).
Processes & Flows:
When a workflow rule triggers an action, it can launch a process or flow. These processes or flows might update records again, potentially leading to additional automated actions.
Roll-up Summary Updates:
For records with roll-up summary fields or those involved in cross-object workflows, Salesforce actively calculates and updates these fields in parent or even grandparent records. These parent/grandparent records then go through their save procedures.
Criteria-Based Sharing:
When saving a record, Salesforce checks criteria-based sharing rules to determine who can see each record.
DML Operations:
DML (data manipulation language) allows you to make additional updates or deletions to related records, even after you’ve saved the initial changes.
Commit & Post-Commit Actions:
Salesforce permanently saves all changes to the database (commits) and then executes post-commit actions like outbound messages and sending emails,
Why do we need an Order of Execution in Salesforce?
By understanding this order, you can ensure the smooth functioning of your automation, maintain data integrity, and build reliable applications on the Salesforce platform.
-
Data Integrity: It plays a crucial role in maintaining the accuracy and consistency of your data. By following the sequence, the system prevents conflicts that may arise if different automations attempt to modify the same data simultaneously. For instance, a validation rule might disallow saving a record with missing data, even if a workflow rule attempts to update that missing field later in the process.
-
Predictable Behavior: Understanding the order ensures that your automation (such as triggers and workflows) executes in the sequence. This predictability enables you to build reliable automation that achieves the desired outcomes without any unexpected interruptions or errors.
-
Efficient Automation: The order allows for optimized automation workflows. If you know when specific actions occur, you can trigger them at the perfect moment to optimize the process. For example, We can send an email notification after the record is saved and all validations are complete.
-
Reduced Errors: The defined order prevents conflicts that might arise from overlapping actions. Let’s say one automation calculates a field value just before saving, and another tries to update it afterward. This could cause Conflicts. The order avoids this issue by ensuring a clear sequence of execution.
-
Troubleshooting Issues: If you encounter problems with your automation, understanding the order of execution can help you pinpoint the source of the issue. By knowing when specific actions occur, you can trace the flow of data and identify where things might be going wrong.
Also, Learn more about The Future of User Access Management in Salesforce
FAQs
1 . What is the order in which Salesforce executes events when we save a record?
Saving a record in Salesforce triggers a specific sequence: 1. Validations (ensure data meets criteria). 2. Triggers & workflows (customizable actions before/after save). 3. System actions (assignments, emails, final data processing).
2. Which will execute the first process builder or flow in Salesforce?
In Salesforce, Flow executions take priority over Process Builder. Process Builder helps you to initiate flows but flows can not directly trigger Process Builders. This means Flows generally execute first, offering more power and flexibility for automation.
3. Which executes the first trigger or flow?
In Salesforce, Salesforce executes record-triggered flows specifically configured to run before the record is saved. After the record-triggered flows, Salesforce executes all before triggers.
Conclusion
From this blog, we can get to know that Salesforce doesn’t just blindly save your records! It follows a specific order, called the Order of Execution, to process data and ensure everything runs smoothly. This order dictates the sequence of various actions, like validation rules, workflows, triggers, and database updates. Understanding this sequence is crucial for optimizing how Salesforce operates and maximizing its efficiency.
One thought on “Order of execution in Salesforce”