Salesforce triggers real-time scenarios Part -1

What is a Trigger?

A trigger in Salesforce is a piece of Apex code that executes before or after specific database operations on Salesforce records. Triggers allow developers to automate processes and enforce business rules by responding to changes in data. They are commonly used to perform actions such as validating data, updating related records, sending notifications, and creating new records based on changes to existing records.

Types of Triggers

Triggers can be classified into two main types based on when they execute:

1. Before Triggers
   • Execution Timing: These triggers run before a record is inserted, updated, or deleted.
   • Use Cases: They are typically used for validation, modifying field values before the record is saved, or preventing operations. For example, a before trigger can ensure that a field value meets specific criteria before allowing the record to be inserted.
2. After Triggers
   • Execution Timing: These triggers run after a record has been inserted, updated, or deleted.
   • Use Cases: They are often used to perform actions that require the record to be committed to the database first. For example, after triggers can be used to create related records, send notifications, or update fields on related records.

Trigger Context Variables

Salesforce provides context variables in triggers to allow developers to access information about the trigger execution context. The key context variables include:

1. Trigger.new
   • Description: A list of the new versions of the records being processed (for insert and update operations).
   • Use Case: Used to access field values of the records that are being inserted or updated.
2. Trigger.old
   • Description: A list of the old versions of the records being processed (only available for update and delete operations).
   • Use Case: Used to access field values of the records before the update or delete operation.
3. Trigger.newMap
   • Description: A map of the new versions of the records, with the record ID as the key.
   • Use Case: Allows for efficient access to new record values by ID.
4. Trigger.oldMap
   • Description: A map of the old versions of the records, with the record ID as the key.
   • Use Case: Allows for efficient access to old record values by ID.
5. Trigger.isInsert
   • Description: A boolean value indicating whether the trigger was fired due to an insert operation.
   • Use Case: Used to conditionally execute code based on whether the trigger is for an insert.
6. Trigger.isUpdate
   • Description: A boolean value indicating whether the trigger was fired due to an update operation.
   • Use Case: Used to conditionally execute code based on whether the trigger is for an update.
7. Trigger.isDelete
   • Description: A boolean value indicating whether the trigger was fired due to a delete operation.
   • Use Case: Used to conditionally execute code based on whether the trigger is for a delete.
8. Trigger.isBefore
   • Description: A boolean value indicating whether the trigger is a before trigger.
   • Use Case: Used to conditionally execute code based on whether the trigger is executed before a DML operation.
9. Trigger.isAfter
   • Description: A boolean value indicating whether the trigger is an after trigger.
   • Use Case: Used to conditionally execute code based on whether the trigger is executed after a DML operation.

Trigger Execution Order

When multiple triggers are defined on the same object, Salesforce enforces a specific order of execution:

1. Before triggers (in the order they are defined)
2. Validation rules
3. After triggers (in the order they are defined)
4. Workflow rules
5. Processes (Process Builder)
6. Escalation rules
7. Assignment rules
8. Entitlement rules
9. Auto-response rules
10. Roll-up summary calculations

Best Practices for Writing Triggers

Avoid Recursive Triggers: Implement logic to prevent triggers from being called recursively, which can lead to governor limit issues.

One Trigger per Object: Aim to have a single trigger per object to simplify maintenance and understanding.

Logic-less Triggers: Keep the trigger code minimal and delegate logic to handler classes. This separation makes code easier to test and maintain.

Bulkification: Ensure your trigger can handle multiple records at once. Use collections (lists, sets, maps) to manage bulk data.

It’s important to have a foundational understanding of several key concepts:

1. Apex Programming Language: Familiarity with Apex, Salesforce’s proprietary programming language, is essential for writing triggers and test classes.
2. Salesforce Object Model: Understanding the standard and custom objects in Salesforce will help you comprehend how triggers interact with data.
3. Trigger Lifecycle: Knowledge of the different trigger events (before insert, after update, etc.) will enable you to implement logic appropriately.
4. SOQL (Salesforce Object Query Language): Proficiency in querying records will allow you to retrieve and manipulate data within your triggers.
5. Best Practices for Test Classes: Knowing how to write effective test classes is crucial for ensuring your code is robust and meets Salesforce’s deployment requirements.

Some scenarios where Salesforce triggers are commonly used, along with brief explanations for each:

1. Data Validation

• Scenario: Ensuring that certain fields meet specific criteria before a record is saved. For example, validating that an email address follows a certain format or that a phone number contains only digits.

2. Automating Related Record Updates

• Scenario: When a record is created or updated, automatically updating related records. For example, updating the LastContactedDate on an Account when a Contact is updated.

3. Preventing Invalid State Changes

• Scenario: Preventing users from making invalid changes to a record. For example, restricting a Case from being closed if its priority is set to “High.”

4. Creating Related Records

• Scenario: Automatically creating records in response to changes in other records. For instance, creating a Task for the owner of a Case when it is escalated.

5. Logging Changes

• Scenario: Maintaining an audit trail by logging changes to critical records. For example, logging ownership changes in a custom object when the owner of an Account changes.

6. Automating Email Notifications

• Scenario: Sending automated email alerts when specific conditions are met, such as notifying the support team when a new Case is created.

7. Updating Field Values Based on Business Logic

• Scenario: Automatically setting field values based on other field values. For example, updating the Stage of an Opportunity to “High Value” if the amount exceeds a certain threshold.

8. Synchronizing Data Across Objects

• Scenario: Keeping data synchronized between different objects. For example, updating product stock levels when an Opportunity is marked as closed won.

9. Custom Business Processes

• Scenario: Implementing custom business logic that does not fit within standard workflow rules. This includes complex operations that involve multiple records or conditions.

10. Enforcing Business Rules

• Scenario: Automatically enforcing business rules that need to be adhered to. For example, preventing a user from submitting a Lead without a valid email address