Top 15 Salesforce Triggers interview questions

1. What is a Salesforce trigger and when would you use it?

A Salesforce trigger is an Apex script that executes before or after specific data manipulation language (DML) events occur, such as insert, update, delete, or undelete. Triggers are used to perform custom actions when a record is manipulated. For instance, if you need to automatically update related records, enforce complex business logic, or integrate with external systems, triggers provide a powerful and flexible way to achieve this. They are particularly useful when the functionality required cannot be achieved through point-and-click tools like Workflow Rules, Process Builder, or Flow.

2. What are the different types of triggers in Salesforce?

Salesforce triggers can be categorized into two types based on their timing relative to the DML event: before and after triggers. Before triggers are executed before a record is saved to the database, allowing you to update or validate values before the changes are committed. After triggers are executed after a record has been saved to the database, making it possible to access and work with the final database values. This distinction is crucial because before triggers can be used to modify the record that is being inserted or updated, while after triggers are typically used for actions such as updating related records or sending notifications, as they rely on the final values being committed to the database.

3. Explain the syntax for defining a trigger in Salesforce.

The syntax for defining a trigger in Salesforce is straightforward and follows a specific structure. A trigger is defined using the trigger keyword, followed by the trigger name, the Salesforce object it is associated with, and the DML events it responds to. Here’s an example of a trigger that executes before an insert on the Account object:

apexCopy codetrigger AccountTrigger on Account (before insert) {
    // Trigger logic here
}

In this example, AccountTrigger is the name of the trigger, Account is the object it is associated with, and before insert specifies that this trigger will execute before an insert operation. Inside the curly braces {}, you would include the logic you want to run when the trigger fires.

4. What are trigger context variables and how are they used?

Trigger context variables in Salesforce are special variables provided by the Apex runtime to help developers identify the context in which the trigger is executing. They provide information about the records being processed and the type of DML operation that is occurring. Some commonly used context variables include Trigger.isInsert, Trigger.isUpdate, Trigger.isDelete, Trigger.new, Trigger.old, Trigger.newMap, and Trigger.oldMap.

For example, Trigger.new holds a list of the new records that are being inserted or updated, while Trigger.old contains the old versions of records before they were updated or deleted. These context variables are essential for writing logic that accurately responds to the specific details of the DML event, ensuring that the trigger performs the desired actions based on the operation type and the data involved.

5. What is the difference between before and after triggers?

The primary difference between before and after triggers lies in their execution timing relative to the DML operation and their use cases. Before triggers run before a record is saved to the database, allowing you to make changes to the record before it is committed. This makes before triggers ideal for validation or setting default values on records. For instance, you can use a before trigger to ensure that certain fields meet specific criteria before allowing the record to be saved.

After triggers, on the other hand, run after a record has been saved to the database. They are used for actions that require the final, committed values of the record. After triggers are commonly used to update related records, send notifications, or perform calculations that depend on the record’s final state. Since after triggers have access to the committed data, they are well-suited for tasks that need to ensure data integrity across multiple related records.

6. How do you avoid recursion in triggers?

Recursion in triggers can lead to infinite loops, which can cause performance issues or even prevent records from being saved. To avoid recursion, it is important to implement mechanisms that ensure a trigger does not repeatedly call itself. One common approach is to use static variables in an Apex class. Static variables retain their values throughout the execution context and can be used to keep track of whether a trigger has already run for a given context.

Here’s an example of how to use a static variable to prevent recursion:

public class TriggerHelper {
    public static Boolean isTriggerExecuted = false;
}

trigger AccountTrigger on Account (before insert, before update) {
    if (TriggerHelper.isTriggerExecuted) {
        return;
    }

    TriggerHelper.isTriggerExecuted = true;

    // Trigger logic here

    TriggerHelper.isTriggerExecuted = false;
}

In this example, the isTriggerExecuted variable is checked at the beginning of the trigger. If it is true, the trigger exits immediately, preventing any further execution. If it is false, the trigger sets it to true, executes the trigger logic, and then resets it to `false.

7. Explain how to handle bulk data in triggers.

Salesforce triggers must be designed to handle bulk data efficiently, as they can process up to 200 records at a time. To ensure triggers can handle bulk operations, follow these best practices:

1. Use Collections: Work with lists, sets, and maps to process multiple records in a single operation. Avoid writing logic that processes records one at a time.
2. Avoid SOQL Queries Inside Loops: Performing SOQL queries or DML operations inside loops can quickly lead to governor limit exceptions. Instead, gather the necessary data using a single SOQL query outside the loop, and then process the results within the loop.
3. Use Efficient Data Structures: Use maps to store and access data efficiently. For example, if you need to fetch related records, use a map to store them by their IDs for quick lookup.
4. Write Test Methods: Ensure your triggers are tested with bulk data to confirm they handle large volumes of records correctly.

Here’s an example of a bulk-safe trigger:

trigger AccountTrigger on Account (before insert, before update) {
    Set<Id> accountIds = new Set<Id>();
    
    for (Account acc : Trigger.new) {
        accountIds.add(acc.Id);
    }
    
    Map<Id, Account> relatedAccounts = new Map<Id, Account>(
        [SELECT Id, Name FROM Account WHERE Id IN :accountIds]
    );
    
    for (Account acc : Trigger.new) {
        if (relatedAccounts.containsKey(acc.Id)) {
            // Process each account record
        }
    }
}

8. How do you write a trigger to handle multiple events?

A single trigger can handle multiple events by specifying multiple DML events in the trigger definition and using context variables to differentiate between them. This allows you to consolidate logic for different events into one trigger, making the code easier to manage and understand.

Here’s an example of a trigger that handles both before insert and before update events:

trigger AccountTrigger on Account (before insert, before update) {
    if (Trigger.isInsert) {
        for (Account acc : Trigger.new) {
            // Logic for before insert
        }
    }
    
    if (Trigger.isUpdate) {
        for (Account acc : Trigger.new) {
            // Logic for before update
        }
    }
}

In this example, the Trigger.isInsert and Trigger.isUpdate context variables are used to determine the type of event and execute the corresponding logic. This approach ensures that the appropriate actions are taken based on the specific DML event.

9. What are some best practices for writing triggers in Salesforce?

Writing efficient and maintainable triggers in Salesforce involves adhering to several best practices:

1. One Trigger Per Object: Aim to have a single trigger per object to avoid conflicts and ensure easier management. Consolidate logic within the trigger using helper classes and methods.
2. Bulkify Your Code: Ensure your trigger can handle bulk data by using collections and avoiding SOQL queries and DML operations inside loops.
3. Use Context Variables: Leverage trigger context variables to write flexible and context-aware logic.
4. Follow Naming Conventions: Use clear and descriptive names for your triggers and related helper classes to make your code easier to understand.
5. Write Comprehensive Test Classes: Ensure your triggers are covered by thorough test classes that test both bulk operations and edge cases.
6. Handle Recursion: Implement logic to prevent recursion, such as using static variables to track trigger execution.
7. Limit SOQL and DML Operations: Minimize the number of SOQL queries and DML operations to stay within governor limits.

By following these best practices, you can create triggers that are efficient, maintainable, and robust.

10. Can you give an example of a trigger that updates a related record?

Updating related records is a common use case for Salesforce triggers. Here’s an example of a trigger that updates the ParentAccount field on a child Account record whenever the Name field of the parent Account is changed:

trigger UpdateChildAccounts on Account (after update) {
    Set<Id> parentAccountIds = new Set<Id>();
    
    for (Account parentAcc : Trigger.new) {
        if (parentAcc.Name != Trigger.oldMap.get(parentAcc.Id).Name) {
            parentAccountIds.add(parentAcc.Id);
        }
    }
    
    if (!parentAccountIds.isEmpty()) {
        List<Account> childAccounts = [SELECT Id, ParentId FROM Account WHERE ParentId IN :parentAccountIds];
        
        for (Account childAcc : childAccounts) {
            childAcc.ParentAccount__c = 'Updated Name: ' + Trigger.newMap.get(childAcc.ParentId).Name;
        }
        
        update childAccounts;
    }
}

In this example, the trigger checks if the Name field of the parent Account has changed. If it has, it retrieves the related child Account records and updates the ParentAccount__c custom field with the new name of the parent account. The changes are then committed using a bulk update operation to ensure efficient processing.

11. How do you test triggers in Salesforce?

Testing triggers in Salesforce involves writing Apex test classes that cover the various scenarios your trigger might encounter. These test classes should validate that your trigger behaves as expected, including handling bulk operations and edge cases. Here’s how to effectively test a trigger:

1. Create Test Data: Set up the necessary test data within your test class. This might involve creating records that will trigger the logic you want to test.
2. Use System.runAs: If your trigger involves different user profiles or permissions, use the System.runAs method to simulate the behavior of different users.
3. Bulk Testing: Ensure your test covers bulk operations by inserting, updating, or deleting multiple records at once.
4. Assertions: Use assertions to validate that the expected changes occurred. Assertions check the state of records before and after the trigger execution.
5. Isolate Tests: Use the @isTest annotation and the Test.startTest and Test.stopTest methods to isolate test execution and manage governor limits.

Here’s an example of a simple test class for a trigger:

@isTest
public class AccountTriggerTest {
    @isTest
    static void testAccountTrigger() {
        // Create test data
        Account testAccount = new Account(Name = 'Test Account');
        insert testAccount;

        // Update test data
        testAccount.Name = 'Updated Test Account';
        update testAccount;

        // Verify the trigger logic
        Account updatedAccount = [SELECT Id, Name FROM Account WHERE Id = :testAccount.Id];
        System.assertEquals('Updated Test Account', updatedAccount.Name);
    }
}

12. Explain the order of execution in Salesforce when a record is saved.

When a record is saved in Salesforce, a specific sequence of events occurs to ensure data integrity and enforce business rules. The order of execution is as follows:

1. System Validation Rules: Salesforce performs system validation rules on the record.
2. Before Triggers: Executes before triggers.
3. Custom Validation Rules: Salesforce runs custom validation rules.
4. Duplicate Rules: Salesforce checks for duplicate records if duplicate rules are defined.
5. After Triggers: Executes after triggers.
6. Assignment Rules: Executes assignment rules.
7. Auto-response Rules: Executes auto-response rules.
8. Workflow Rules: Executes workflow rules.
9. Processes and Flows: Executes processes and flows created in Process Builder.
10. Escalation Rules: Executes escalation rules if the record is a case.
11. Entitlement Rules: Executes entitlement rules if the record is a case.
12. Roll-Up Summary Fields: Updates roll-up summary fields if necessary.
13. Parent Roll-Up Summary Fields: Updates parent roll-up summary fields if necessary.
14. Criteria-Based Sharing Rules: Evaluates and applies criteria-based sharing rules.
15. Commit: Salesforce commits the transaction to the database.
16. Post-Commit Logic: Executes post-commit logic such as sending email notifications and executing asynchronous Apex (e.g., future methods and queueable jobs).

Understanding this order is crucial for developing effective triggers and workflows, as it helps anticipate the sequence in which different automations and custom logic will be applied.

13. How can you prevent a trigger from running?

To prevent a trigger from running, you can use various strategies depending on the specific requirements. Here are a few common approaches:

Static Variables: Use static variables to control the execution flow of your triggers. You can set a static variable to indicate whether the trigger should run or not.

public class TriggerControl {
    public static Boolean preventTrigger = false;
}

trigger AccountTrigger on Account (before insert, before update) {
    if (TriggerControl.preventTrigger) {
        return;
    }

    // Trigger logic here
}

Custom Settings or Custom Metadata: Use custom settings or custom metadata types to enable or disable triggers dynamically. This approach allows administrators to control trigger execution without modifying code.

trigger AccountTrigger on Account (before insert, before update) {
    if (CustomSetting__c.getInstance().Disable_Account_Trigger__c) {
        return;
    }

    // Trigger logic here
}

User Context: Use conditional checks based on the running user’s context, such as profile or role, to control whether the trigger should execute.

trigger AccountTrigger on Account (before insert, before update) {
    if (UserInfo.getProfileId() == [SELECT Id FROM Profile WHERE Name = 'System Administrator'].Id) {
        return;
    }

    // Trigger logic here
}

14. What is the use of the Trigger.new and Trigger.old variables?

Trigger.new and Trigger.old are context variables available in Salesforce triggers that provide access to the records being processed. They play a crucial role in handling different DML events and writing trigger logic.

• Trigger.new: This context variable is a list of the new versions of the records that are being inserted or updated. It is available in before insert, before update, after insert, and after update triggers. Trigger.new allows you to access and modify the new values of the records before they are saved to the database (in before triggers) or to perform actions based on the new values (in after triggers).
• Trigger.old: This context variable is a list of the old versions of the records that are being updated or deleted. It is available in before update, after update, before delete, and after delete triggers. Trigger.old provides access to the original values of the records before the DML event occurred, allowing you to compare old and new values to implement logic based on changes.

Here’s an example of using Trigger.new and Trigger.old in an update trigger:

trigger AccountTrigger on Account (before update) {
    for (Account acc : Trigger.new) {
        Account oldAcc = Trigger.oldMap.get(acc.Id);
        if (acc.Name != oldAcc.Name) {
            // Logic to handle name change
        }
    }
}

15. Describe a scenario where you would use a trigger over a workflow rule or process builder.

Triggers are preferred over workflow rules or Process Builder in scenarios where more complex logic is required, or when the functionality needed cannot be achieved through declarative tools. For example, consider a scenario where you need to:

1. Perform Cross-Object Updates: If you need to update fields on related records across different objects, triggers offer the necessary flexibility. For instance, if changing the status of an opportunity should update a custom field on all related account records, a trigger can be used to achieve this.
2. Handle Complex Calculations: When business logic involves complex calculations or multi-step processes that cannot be defined using declarative tools, triggers provide the control and capabilities needed. For instance, calculating a weighted average score based on multiple related child records requires logic that can be efficiently implemented in a trigger.
3. Implement Conditional Logic Based on Multiple Factors: If the logic depends on multiple conditions and involves various steps, triggers can handle this more effectively than workflow rules or Process Builder. For example, if a case’s priority should be automatically updated based on a combination of its type, status, and related account’s tier, a trigger can encapsulate this logic in a maintainable manner.
4. Perform Actions Not Supported by Declarative Tools: There are certain actions, such as creating or updating records across unrelated objects, sending HTTP requests, or invoking custom business logic, that are not supported by workflow rules or Process Builder. In such cases, triggers provide the necessary flexibility and power.

In summary, while declarative tools are suitable for many standard automation tasks, triggers are essential for handling advanced use cases that require complex, conditional, or cross-object logic.

Looking to master Salesforce and advance your career? Join our dynamic Salesforce training program in Hyderabad, meticulously crafted to deliver real-time knowledge and practical expertise. Engage in immersive, project-based learning enriched with daily notes, hands-on projects, and targeted preparation for certifications and interviews, ensuring you’re fully equipped for the Salesforce landscape.

Seize the opportunity to transform your skills and career trajectory. Enroll today in our Salesforce course and benefit from personalized mentorship by seasoned instructors. Whether you’re starting from scratch or aiming to refine your Salesforce proficiency, our tailored training in Hyderabad is designed to empower your success. Take the leap forward in your professional journey with us.