What is a Trigger? Definition, Types, and Examples in Technology

By step2career
Salesforce Triggers






What is a Trigger?


What is a Trigger?

In the realm of software development, especially within platforms like Salesforce, a Trigger is a powerful piece of code that acts as an automated response mechanism. Essentially, it’s a block of Apex code designed to execute automatically *before* or *after* specific data manipulation language (DML) events occur on a Salesforce object. These events are the fundamental ways we interact with data:

  • insert: When a new record is created.
  • update: When an existing record is modified.
  • delete: When a record is removed.
  • undelete: When a deleted record is restored.

Triggers are indispensable for implementing intricate business logic, enforcing data validation rules that go beyond standard capabilities, and automating processes that require more sophisticated handling. They provide developers with the ability to programmatically react to changes in records and execute custom actions, filling gaps where declarative tools like Workflow Rules or Process Builder might fall short.

Types of Triggers

Salesforce categorizes triggers into two main types, distinguished by their execution timing relative to the DML operation. This distinction is crucial for understanding what actions can be performed at each stage.

Before Triggers

These triggers fire before the database operation is committed. Think of them as gatekeepers. Their primary uses include:

  • Validating or Modifying Field Values: You can check if data meets certain criteria or even change field values before they’re permanently stored. For instance, you might auto-format a phone number or ensure a certain field is populated based on another.
  • Operations Not Requiring an ID: For newly inserted records, a unique ID hasn’t been assigned yet. Before triggers are suitable for actions that don’t depend on the record’s ID.
  • Preventing DML Operations: By throwing an exception (an error message), a before trigger can halt the DML operation entirely, ensuring data integrity.

After Triggers

These triggers execute after the database operation has completed and the record has been successfully saved. They are your go-to for actions that need to happen once the data is in the system:

  • Accessing Committed Field Values: You can work with the data as it exists in the database, including fields that might have been populated by other automated processes or system fields.
  • Performing Actions on Related Records: This is a very common use case. After an Opportunity is closed, an after trigger might update a parent Account’s “Total Revenue” field or create a related Task for a follow-up.
  • Making Callouts to External Systems: After data is saved, you can trigger integrations to send this data to other applications. However, this requires careful planning due to governor limits and often necessitates asynchronous processing.
  • Sending Notifications: After a record is created or updated, an after trigger can send an email notification to relevant parties.

Trigger Context Variables

When a trigger fires, Salesforce provides a set of special variables, known as Trigger Context Variables. These variables offer invaluable insight into the event that caused the trigger to execute and the data involved. Understanding these is key to writing effective triggers:

  • Trigger.new: A list containing the new versions of the records being processed. For inserts and updates, this is what the records will look like after the operation.
  • Trigger.old: A list containing the old versions of the records being processed. This is available only for update and delete triggers, showing the state of the records *before* the operation.
  • Trigger.newMap: A map where keys are record IDs and values are the new versions of the records. This is incredibly useful for quickly looking up records by their ID.
  • Trigger.oldMap: Similar to newMap, but for the old versions of records. Available in update and delete triggers.
  • Trigger.isInsert, Trigger.isUpdate, Trigger.isDelete, Trigger.isUndelete: These are boolean variables that tell you exactly which type of DML operation is currently happening. Only one of these will be true at a time.
  • Trigger.isBefore, Trigger.isAfter: Boolean variables indicating whether the currently executing trigger is a `before` or `after` trigger.
  • Trigger.size: Simply tells you how many records are in the Trigger.new list. This is vital for bulkification.
  • Trigger.operationType: An enum value that precisely describes the DML operation, useful for more granular control.

For more detailed information on these variables, refer to the official Salesforce Apex Developer Guide: Trigger Context Variables.

Interview Questions and Answers

1. What is a Salesforce Trigger and why would you use one?

Answer: A Salesforce Trigger is Apex code that automatically executes before or after data manipulation language (DML) events like insert, update, delete, or undelete occur on a record. We use triggers to enforce complex business rules, automate processes, perform calculations, update related records, or integrate with external systems when declarative tools (like Workflow Rules or Process Builders) are insufficient or lack the necessary flexibility.

2. What’s the difference between a ‘before’ and an ‘after’ trigger? When would you use each?

Answer: Before triggers run *before* the record is saved to the database. They are ideal for validating or modifying field values *before* they are committed, or for preventing an operation by throwing an error. After triggers run *after* the record is saved. They are used for actions that require the record ID to be available (as it’s assigned upon saving), such as updating related records, performing callouts to external systems, or sending notifications.

3. What are Trigger Context Variables? Give some examples and their uses.

Answer: Context variables are built-in variables that provide information about the triggering event. Examples include Trigger.new (the new version of records being processed), Trigger.old (the previous version of records, available for updates/deletes), Trigger.isInsert (true if it’s an insert operation), and Trigger.isBefore (true if it’s a before trigger). These help us understand the context and data of the operation.

4. How do you prevent a trigger from running multiple times for the same record in a single transaction?

Answer: You use a static boolean variable within your trigger handler class to track if a specific operation has already been performed in the current transaction. This is often referred to as a “recursive trigger” prevention mechanism. For example, you might set a static boolean `hasRun` to true after the first execution and check it before proceeding.

5. What are trigger handlers and why are they important?

Answer: Trigger handlers are Apex classes that contain the actual logic for your triggers. They help to decouple the trigger definition (which simply calls methods in the handler) from the complex business logic itself. This makes the code more organized, reusable, maintainable, and easier to test. You typically have one trigger per object and delegate all its logic to handler classes.

6. What is the difference between Trigger.new and Trigger.old?

Answer: Trigger.new contains the latest version of records that are being inserted or updated. Trigger.old contains the previous version of records that are being updated or deleted. Trigger.old is not available for insert or undelete operations because there is no “previous” version in those contexts.

7. What are some common pitfalls when writing triggers?

Answer: Common pitfalls include:

  • Recursive Triggers: Triggers that call themselves, leading to infinite loops and errors.
  • Bulkification Issues: Not handling multiple records at once, leading to hitting governor limits for SOQL queries or DML statements.
  • Hardcoding IDs: Embedding record IDs directly in the trigger logic, making it fragile and difficult to maintain.
  • Inefficient SOQL Queries: Performing SOQL queries inside loops, which is a primary cause of governor limit errors.
  • Not considering Order of Execution: Not understanding how triggers interact with other declarative automation (workflows, process builders, etc.) and system events, leading to unexpected behavior.

8. How would you handle a scenario where a trigger needs to update a related parent record?

Answer: You would typically use an after insert or after update trigger. You would first gather the IDs of the child records that triggered the event. Then, you’d query the related parent records. After performing the necessary calculations or updates based on the child records, you’d then execute a DML operation on the parent records. Using Trigger.newMap and Trigger.oldMap can be very efficient for this.

Troubleshooting Common Trigger Issues

Governor Limit Errors: “Too many SOQL queries: 101” or “Too many DML rows: 201”

Cause: This is the most frequent culprit. It means your trigger is not processing records in bulk. You might be querying or performing DML inside a loop.

Solution: Ensure all SOQL queries and DML statements are outside loops. Collect all necessary IDs and perform a single query or DML operation for the entire batch of records processed by the trigger. Use Trigger.new.size to know how many records you’re dealing with.

“System.FinalException: Cannot modify immutable…”

Cause: You’re attempting to change a field in a before trigger that cannot be modified after it has been initially set. Common examples include the record’s ID or certain system-managed audit fields.

Solution: Identify which fields are immutable and avoid modifying them in your before triggers. If you need to update a record, you might need to do it in an after trigger or adjust your logic.

Trigger Not Firing

Cause: Several reasons could be at play: the trigger might be inactive, the DML operation is on a different object, or other automation is preventing it. It could also be that the user performing the action lacks permissions or the action is part of an integration with specific settings.

Solution:

  • Verify the trigger is active in the Salesforce Setup.
  • Confirm the DML operation is on the correct object the trigger is defined for.
  • Check if any other automation (workflows, Process Builders, other triggers) might be interfering.
  • If the action is from an integration, ensure the integration user has the necessary permissions and that no specific trigger exclusion rules are in place.

Unexpected Data Changes

Cause: This is often due to subtle logic in before triggers modifying fields unintentionally, or after triggers causing cascading updates. The order of execution can also be a factor.

Solution:

  • Carefully review the logic in your before triggers, especially for field modifications.
  • Examine after triggers that update related records.
  • Consider the Salesforce Order of Execution and how your trigger fits in with other automation. Debugging logs are invaluable here.

“UNABLE_TO_LOCK_ROW”

Cause: This usually indicates a lock contention issue. One transaction is holding a lock on a record (or set of records) that another transaction needs. Long-running triggers or complex automation that locks many records can cause this.

Solution: Optimize your trigger logic to be as efficient as possible, minimizing the time spent processing. Try to reduce the scope of records being locked. If possible, redesign automation to avoid locking records unnecessarily or for extended periods.

Practical Examples

1. Auto-populate an Opportunity ‘Description’ field based on Account Industry (Before Insert/Update)

This example shows how to update a field on the Opportunity before it’s saved, based on information from its related Account.


// Trigger on Opportunity Object
trigger OpportunityTrigger on Opportunity (before insert, before update) {
    if (Trigger.isBefore) {
        OpportunityTriggerHandler.updateDescription(Trigger.new);
    }
}

// Trigger Handler Class
public class OpportunityTriggerHandler {
    public static void updateDescription(List<Opportunity> newOpps) {
        Set<Id> accountIds = new Set<Id>();
        for (Opportunity opp : newOpps) {
            // Collect Account IDs if they exist on the opportunity
            if (opp.AccountId != null) {
                accountIds.add(opp.AccountId);
            }
        }

        // If we have Account IDs to process
        if (!accountIds.isEmpty()) {
            // Query the related Accounts to get their industries
            Map<Id, Account> accountMap = new Map<Id, Account>([
                SELECT Id, Industry FROM Account WHERE Id IN :accountIds
            ]);

            // Iterate through the opportunities again to update descriptions
            for (Opportunity opp : newOpps) {
                if (opp.AccountId != null && accountMap.containsKey(opp.AccountId)) {
                    Account acc = accountMap.get(opp.AccountId);
                    if (acc.Industry != null) {
                        opp.Description = 'This opportunity is with an account in the ' + acc.Industry + ' industry.';
                    }
                }
            }
        }
    }
}

Explanation: This before insert and before update trigger uses a handler class. It first collects all unique AccountIds from the opportunities being processed. Then, it performs a single, bulkified SOQL query to fetch the `Industry` from the corresponding Accounts. Finally, it iterates through the opportunities again to populate the Description field. Since this is a before trigger, modifying opp.Description directly within Trigger.new automatically updates the record before it’s saved.

2. Update Parent Account’s ‘Total Opportunities’ Count (After Insert/Update/Delete)

This example demonstrates how to maintain a roll-up summary on the parent Account when Opportunities are added, modified, or removed.


// Trigger on Opportunity Object
trigger OpportunityTrigger on Opportunity (after insert, after update, after delete) {
    if (Trigger.isAfter) {
        OpportunityTriggerHandler.updateAccountOpportunityCount(Trigger.new, Trigger.old, Trigger.operationType);
    }
}

// Trigger Handler Class
public class OpportunityTriggerHandler {
    public static void updateAccountOpportunityCount(List<Opportunity> newOpps, List<Opportunity> oldOpps, TriggerOperation operation) {
        Set<Id> accountIdsToUpdate = new Set<Id>();

        // Add Account IDs from new records (inserts and updates)
        if (newOpps != null) {
            for (Opportunity opp : newOpps) {
                if (opp.AccountId != null) {
                    accountIdsToUpdate.add(opp.AccountId);
                }
            }
        }

        // Add Account IDs from old records (updates and deletes)
        if (oldOpps != null) {
            for (Opportunity opp : oldOpps) {
                if (opp.AccountId != null) {
                    accountIdsToUpdate.add(opp.AccountId);
                }
            }
        }

        // If no accounts are affected, exit early
        if (accountIdsToUpdate.isEmpty()) {
            return;
        }

        // Get the current state of affected accounts
        Map<Id, Account> accounts = new Map<Id, Account>([
            SELECT Id, Name, Total_Opportunities__c FROM Account WHERE Id IN :accountIdsToUpdate
        ]);

        // Prepare a map to hold the new counts for each account
        Map<Id, Integer> accountOpportunityCounts = new Map<Id, Integer>();
        // Initialize counts to zero for all affected accounts
        for (Id accId : accountIdsToUpdate) {
            accountOpportunityCounts.put(accId, 0);
        }

        // Query ALL open opportunities for the affected accounts to get an accurate count
        // This is important because trigger.new/old might not contain all opportunities
        List<Opportunity> allOpportunitiesForAccounts = [
            SELECT Id, AccountId FROM Opportunity WHERE AccountId IN :accountIdsToUpdate
        ];

        // Calculate the new counts
        for (Opportunity opp : allOpportunitiesForAccounts) {
            if (opp.AccountId != null) {
                accountOpportunityCounts.put(opp.AccountId, accountOpportunityCounts.get(opp.AccountId) + 1);
            }
        }

        // Update the Account records with the new counts
        List<Account> accountsToUpdate = new List<Account>();
        for (Id accId : accountIdsToUpdate) {
            Account acc = accounts.get(accId); // Get the account from the map we queried earlier
            if (acc != null) {
                acc.Total_Opportunities__c = accountOpportunityCounts.get(accId);
                accountsToUpdate.add(acc);
            }
        }

        // Perform DML on the Accounts if there are any to update
        if (!accountsToUpdate.isEmpty()) {
            update accountsToUpdate;
        }
    }
}

Explanation: This after insert, after update, and after delete trigger handles all relevant DML operations. It collects all AccountIds that might be affected, whether from new records being inserted/updated or old records being deleted/updated. It then queries these accounts and, crucially, queries all open opportunities related to these accounts to ensure an accurate, up-to-date count. Finally, it updates the Total_Opportunities__c field on each affected Account. This approach is robust and bulkified.

Technical Notes

  • Governor Limits: Salesforce enforces strict governor limits (e.g., number of SOQL queries, DML statements, CPU time) to ensure the stability of its multi-tenant platform. Triggers must be designed to operate within these limits, which means bulkification is not optional; it’s a necessity. Always process records in batches.
  • Order of Execution: Understanding the Salesforce Order of Execution is critical. Triggers interact with validation rules, assignment rules, workflows, Process Builders, Flow, and other automation. The sequence in which these components execute can significantly impact your trigger’s outcome.
  • Recursion: Avoid recursive triggers at all costs. A trigger that modifies records of the same object it’s running on can lead to an infinite loop. The standard practice is to use static variables within trigger handler classes to ensure a specific logic path is executed only once per transaction.
  • Trigger Frameworks: For larger or more complex Salesforce orgs, consider adopting a trigger framework. These frameworks provide a structured, standardized approach to writing and managing trigger logic, often separating concerns into distinct classes for better organization, reusability, and testability.
  • Testing: Comprehensive unit testing is mandatory for triggers. Write Apex test classes that cover various scenarios, including single-record operations, bulk operations, edge cases (like null values or empty lists), and error conditions, to ensure your triggers behave as expected and don’t violate governor limits.
  • before vs. after for DML:
    • before triggers: Primarily for validation and modifying field values before the record is saved. They can also prevent DML operations.
    • after triggers: Best for performing actions that require the record ID (which is assigned after saving), working with related records, or making callouts to external systems. They cannot directly prevent DML; that’s the role of before triggers.

Real-World Scenarios Where Triggers Shine

  • Data Quality Enforcement: Automatically format phone numbers to a standard pattern, standardize picklist values based on complex logic, or ensure required fields on related records are populated before a primary record is saved.
  • Automated Approval Workflows: When an Opportunity reaches a certain value threshold (e.g., over $100,000), a trigger can automatically create an approval request and assign it to the relevant manager, bypassing manual steps.
  • Custom Roll-up Summaries: While Salesforce offers declarative Roll-Up Summary fields for master-detail relationships, triggers are necessary for more complex aggregations, calculations across unrelated objects, or when you need to update summary fields on records in lookup relationships.
  • Advanced Auditing and Logging: Implement sophisticated custom audit trails by logging changes to critical fields, including who made the change, when, and what the previous and new values were, storing this information in a dedicated custom object.
  • Complex Integration Points: Trigger data synchronization with external systems. For example, when a new Contact is created with a specific “Type” field, a trigger can send its details to an external ERP system or a marketing automation platform.
  • Custom Validation Logic: Implement intricate business rules that cannot be achieved with standard validation rules. This could involve checking for specific combinations of field values across multiple related records or implementing complex cross-object validations.
  • Dynamic Record Assignment: Automatically assign ownership of records (like Leads or Cases) based on sophisticated criteria that go beyond basic round-robin or map-based assignment rules, factoring in territory, product, or other dynamic data.

Triggers are a cornerstone of Salesforce customization, offering unparalleled power and flexibility. However, with great power comes great responsibility. They demand careful design, rigorous testing, and a deep understanding of platform best practices to ensure they enhance, rather than hinder, your application’s performance and stability.