Salesforce Order of Execution Simplified

When dealing with CRM Software you might have come across the word ‘Salesforce’ in the industry. This has certainly led you to ask yourself, ‘What is Salesforce? Salesforce is one of the best cloud-based CRM platforms in the world, designated for customer relationship management and business process optimization. Developers and administrators must understand a critical aspect of Salesforce: They include the order of execution, which explains the order in which operations run when a record is being created, modified, deleted, or undeleted. This article will explain the best-known concept called order of execution in Salesforce, the stages of the Salesforce order of execution, after-commit logic, operations that are not creating triggers, and changes implemented in the Spring ‘22 release.

What is the Order of Execution in Salesforce?

The order of execution can also be easily understood if you have a clue of what Salesforce is all about. It describes the implementation of the sequence of steps involved in creating, updating, deleting, and undeleting a record in the Salesforce platform. Salesforce tutorials can be handy if you are new to their platform.

Knowing the order of execution assists developers and administrators in focusing on how to design the best penetration process of automation and validation rules, besides avoiding some pitfalls, such as getting caught in the loop or having different forms of data.

Thus, when a DML operation occurs, various operations are set in motion to ensure that business rules are applied, data is validated, and automation is performed. The first step is system validation rules, where there are rules to check for all mandatory fields, data types, and field formats. It then goes to before triggers, custom validation rules, and duplicate rules to increase the accuracy of the data and to uphold business logic.

After those preliminary checks, triggers and various other things like assignment rules, auto-responder rules, workflow rules, processes, and flows are executed. These steps guarantee that any additional business logic or automated process is effected before the data is written to the database. Post-commit operations include:

• Carrying out activities such as sending an email.
• Calling a future method.
• Updating an external system later as part of the transaction’s closing.

Understanding this sequence allows developers to predict the behavior of their customizations and integrations, ensuring that all necessary operations are executed in the correct order, thereby maintaining the integrity and functionality of Salesforce applications.

Salesforce Order of Execution

Any DML operation carried out on Salesforce follows the order of operations, ensuring that all the business rules, valid actions, and other processes are activated correctly. Here’s a simplified breakdown of the order of execution: 

• System Validation Rules: Salesforce executes the system-level validation check for mandatory fields, data type and field format checks. Custom validation rules that have been defined, duplicate rules, and escalation rules are also performed at this point.
• Before Triggers: This method is recommended before triggers are executed. These are executed before saving records into the database and allow the developers to alter the record before storing it.
• Custom Validation Rules: Custom rules of validation are defined and used. In case a validation rule is violated, the record is not committed, and an error is produced.
• Duplicate Rules: Records checks are done to avoid creating duplicate records using the rules where necessary. One may be made depending on the rules used for the records.
• After Triggers: The procedure for submitting triggers is followed, and then the triggers are run. The following triggers operate when the record is stored in the database.
• Assignment Rules: Assignment rules are assessed, and the records are subjected to the identified regulations.
• Auto-Response Rules: Auto-response rules are utilized to automatically respond to leads or cases submitted, following regulations laid down by the user.
• Workflow Rules: The Descriptive and business events come next, leading to the execution of the workflow rules, which in turn may include field updates, emails, tasks, or outbound messages.
• Processes and Flows: Processes created by Process Builder and flows outlined by Flow Builder are run. These can perform business logic and other data manipulations and calculations.
• Escalation Rules: Proceeding rules are used with cases that meet the criteria specified when the rule is entered.
• Entitlement Rules: Entitlement rules are assessed concerning any given case to ascertain the most appropriate entitlement process.
• Roll-Up Summary Fields: Additionally, depending on significant changes made to a record wherein they have child records, the roll-up summary fields on the parent record will also be affected.
• Cross-Object Workflow Field Updates: Cross-object workflow field updates are done, and this may activate more validation rules and triggers for other related objects.
• Parent Roll-Up Summary Fields: The parent roll-up summary fields get updated whenever the child records data changes.
• Database Save: The record is at last written to the database.
• Post-Commit Logic: Internal system updates, emails, Future methods, Queueable jobs, and outbound messages are other types of post-commit logic that are run or performed at this stage.

What is Part of the After-commit Logic?

This is another important query that is usually asked under Salesforce interview questions. The after-commit process is done once the record has been dedicated to the database. These operations typically encompass interactions with external systems or processes that may not be required to be carried out before the end of the transaction. Here are some essential elements of after-commit logic:

• Email Notifications: Emails are sent based on the configured workflow rules, process builders, or based on any custom preferences once the record is saved.
• Asynchronous Processing: Future methods, batch Apex, and queueable Apex for Apex classes are initiated to run after the transaction.
• Outbound Messages: Outbound messaging is a transaction; these messages sent to other systems are processed after the record has been saved.
• Platform Events: After the commit is made, other systems or components interested in Salesforce changes receive platform events.
• Update External Systems: The integrations that modify external systems, such as ERP or financial systems, are done post-commit.

Operations That Don’t Invoke Triggers

Here are some key operations that do not invoke triggers:

Manual Sharing:

When users manually share records with other users or groups, Salesforce does not fire triggers. Manual sharing allows for flexible record visibility without altering the data itself or invoking additional automated processes.

Mass Reassignments:

Mass reassignment operations, such as reassigning leads, accounts, or cases to different users, do not trigger the execution of triggers. This feature is useful for administrators who need to reallocate ownership without triggering automated processes that might lead to performance issues or unintended consequences.

Changing Record Owners:

Similar to mass reassignments, changing the owner of a single record does not invoke triggers. This operation is often used for administrative adjustments and ensures that ownership changes do not unintentionally affect business logic or workflows.

Merging Records:

When records are merged, such as by combining duplicate accounts or contacts, Salesforce does not fire triggers for deleted records. This prevents unnecessary execution of business logic that might otherwise process redundant or obsolete data.

Using Import Wizards:

Salesforce’s import wizards allow for easy data import without invoking triggers. This tool is designed for administrators and users to quickly import data without triggering the extensive automation processes that might apply during regular data entry.

Data Loader Upserts:

When using Data Loader to upsert records, triggers are not invoked for records that remain unchanged. This helps optimize performance during bulk data operations, ensuring that only modified records trigger automated processes.

Custom UI Actions:

Certain custom UI actions, such as button clicks that invoke specific logic or workflows, may also bypass triggers, depending on their implementation. This allows for targeted automation without broadly affecting other processes.

Important Considerations for Order of Execution and Changes from Flow Behavior Before and After Spring ‘22 Release

Salesforce’s Spring ’22 release introduced several pivotal changes to the flow behavior and the overall order of execution, which have significant implications for developers and administrators. Understanding these changes is crucial to effectively managing automation processes and ensuring the smooth operation of Salesforce environments. Here’s a detailed look at these considerations and the specific changes brought about by the Spring ‘22 release:

Flow Trigger Order:

Before the Spring ‘22 release, the execution order clearly distinguished workflow rules from record-triggered flows. Record-triggered flows ran after workflow rules. This often led to confusion and unintended behavior, especially when both workflows and flows were used to automate related processes.

The Spring ‘22 release changed this by ensuring that record-triggered flows execute before workflow rules.

This alignment more closely resembles the order of execution of Apex triggers, where ‘before triggers’ run before validation rules and ‘after triggers’ run after the record has been saved. This change streamlines the automation process and provides a more predictable and consistent execution order, simplifying the design and debugging of automation logic.

Scheduled Flows:

Scheduled flows, which are designed to run at specified times or intervals, also saw a significant change. Previously, scheduled flows could start executing before all data transactions were fully committed. This sometimes resulted in inconsistencies, especially when the scheduled flow depended on the outcome of the DML operations.

With the Spring ‘22 release, Salesforce ensures that scheduled flows run only after the transaction is fully committed. This guarantees that all data changes are finalized before the flow begins its execution, thereby improving data integrity and consistency.

Entry Conditions for Flows:

Another important consideration is evaluating flow entry conditions. In earlier versions, flows might have been executed even if the entry conditions were not thoroughly checked at the beginning of the process.

This could lead to unnecessary executions and performance hits. Post Spring ‘22, entry conditions for flows are evaluated right at the start, similar to how validation rules operate. This ensures that flows are triggered only when specific criteria are met, enhancing the efficiency and relevance of automated processes.

Flow Trigger Management:

The Spring ‘22 release also provided administrators with enhanced tools to manage the order of execution for flows. This includes more control over the sequence in which flows are triggered, enabling prioritization of critical business processes. The enhanced management tools allow for better coordination between different automation tools, reducing conflicts and redundant operations.

Conclusion

Understanding the order of execution in Salesforce is crucial for developers and administrators to ensure that business rules are enforced correctly and data integrity is maintained. From system validation rules to post-commit logic, each stage of the order of execution plays a vital role in the platform’s overall functionality. The changes introduced in the Spring ‘22 release further streamline the automation processes, providing more control and flexibility to manage flows and triggers effectively. Know more about it by enrolling in the Salesforce Training Program.

FAQs

What is the order of execution in Salesforce?

The order of execution in Salesforce refers to the sequence of operations that occur when a record is created, updated, deleted, or undeleted. This includes system validations, triggers, workflow rules, processes, and post-commit logic, among other steps.

Which runs first, trigger or flow in Salesforce?

The trigger runs first in Salesforce. This aligns the execution order of flows more closely with triggers.

What is the order of operations in Salesforce triggers?

The order of operations in Salesforce triggers is as follows:

• System validation rules
• Before triggers
• Custom validation rules
• Duplicate rules
• After triggers
• Assignment rules
• Auto-response rules
• Workflow rules
• Processes and flows
• Escalation rules
• Entitlement rules
• Roll-up summary fields
• Cross-object workflow field updates
• Parent roll-up summary fields
• Database save
• Post-commit logic

What are the two types of triggers in Salesforce?

Salesforce supports two types of triggers:

• Before Triggers: Execute before a record is saved to the database. They are typically used to validate or modify record values before committing the record.
• After Triggers: Execute after a record has been saved to the database. They are often used to perform operations that require the record to exist in the database, such as updating related records or sending notifications.