Salesforce Trigger Scenarios: Key Interview Questions

 Below is the Apex trigger that automatically populates the Description field of an Account with "Default Description" whenever a new Account is created.

Object : Account
Trigger: before insert

Trigger Code: AccountDescription.apxt

trigger AccountDescription on Account (before insert) {
    for (Account acc : Trigger.new) {
        if (acc.Description == null) {
            acc.Description = 'Default Description';
        }
    }
}

Expected Output

When a new Account is created without a Description, the trigger will populate it with "Default Description".

 Below is the Apex trigger that prevents the creation of duplicate Contacts based on the Email field. If a Contact with the same email already exists, the trigger will block the creation and display an error message.

The two triggers serve different purposes and handle duplicate detection in different ways. Here’s a breakdown of the differences:

WAY-1
Object : Contact
Trigger: before insert, before update

Trigger Code: PreventDuplicateContacts.apxt

trigger PreventDuplicateContacts on Contact (before insert, before update) {
    Set<String> emailSet = new Set<String>();
    for (Contact con : Trigger.new) {
        if (emailSet.contains(con.Email)) {
            con.addError('Duplicate Email found: ' + con.Email);
        } else {
            emailSet.add(con.Email);
        }
    }
}

What it does

1. Scope: It checks for duplicates only within the current batch of records being inserted or updated in the same transaction.
2. Logic: It uses a Set<String> to track emails within Trigger.new. If an email is encountered more than once in the same batch, it throws an error.
3. Limitation: It does not check for duplicates in the database. It only ensures that no two Contacts in the same batch have the same email.

Use Case

• Prevents duplicates within the same transaction (e.g., if someone tries to insert two Contacts with the same email in one operation).

Expected Output

If a Contact with a duplicate email is inserted or updated, the trigger will throw an error.

WAY-2
Object : Contact
Trigger: before insert

Trigger Code: PreventDuplicateContacts.apxt

trigger PreventDuplicateContacts on Contact (before insert) {
    // Create a set to store unique email addresses from the incoming Contacts
    Set<String> emailSet = new Set<String>();
    for (Contact con : Trigger.new) {
        emailSet.add(con.Email);
    }

    // Query existing Contacts with the same emails
    Map<String, Contact> existingContactsMap = new Map<String, Contact>();
    for (Contact con : [SELECT Id, Email FROM Contact WHERE Email IN :emailSet]) {
        existingContactsMap.put(con.Email, con);
    }

    // Check for duplicates and block creation if a duplicate email is found
    for (Contact con : Trigger.new) {
        if (existingContactsMap.containsKey(con.Email)) {
            con.addError('A Contact with this Email already exists. Duplicate Contacts are not allowed.');
        }
    }
}

What it does

1. Scope: It checks for duplicates across the entire database by querying existing Contacts.
2. Logic: It uses a Set<String> to collect emails from Trigger.new, queries the database for existing Contacts with those emails, and then checks for duplicates.
3. Advantage: It ensures that no Contact is created with an email that already exists in the database, regardless of the transaction.

Use Case

• Prevents duplicates across the entire database (e.g., if someone tries to insert a Contact with an email that already exists in the system).

Expected Output

Key Differences

If you need both functionalities (preventing duplicates within the batch and across the database), you can combine the two approaches. For example:

trigger PreventDuplicateContacts on Contact (before insert, before update) {
    // Check for duplicates within the same batch
    Set<String> emailSet = new Set<String>();
    for (Contact con : Trigger.new) {
        if (emailSet.contains(con.Email)) {
            con.addError('Duplicate Email found within the same batch: ' + con.Email);
        } else {
            emailSet.add(con.Email);
        }
    }

    // Check for duplicates across the database
    Map<String, Contact> existingContactsMap = new Map<String, Contact>();
    for (Contact con : [SELECT Id, Email FROM Contact WHERE Email IN :emailSet]) {
        existingContactsMap.put(con.Email, con);
    }

    for (Contact con : Trigger.new) {
        if (existingContactsMap.containsKey(con.Email)) {
            con.addError('A Contact with this Email already exists in the database. Duplicate Contacts are not allowed.');
        }
    }
}

This combined approach ensures no duplicates are created, both within the batch and across the database.

 Below is the Apex trigger that updates the Phone field of all related Contacts whenever an Account's Phone field is updated. The trigger ensures that the Contacts' phone numbers stay in sync with their parent Account.

The two triggers serve the same purpose—updating the Phone field of related Contacts when an Account's Phone field is updated—but there are some differences in their implementation and efficiency. Let’s break it down:

WAY-1
Object : Account
Trigger: after update

Trigger Code: UpdateContactPhone.apxt

trigger UpdateContactPhone on Account (after update) {
    Set<Id> accountIds = new Set<Id>();
    for (Account acc : Trigger.new) {
        if (acc.Phone != Trigger.oldMap.get(acc.Id).Phone) {
            accountIds.add(acc.Id);
        }
    }
    if (!accountIds.isEmpty()) {
        // Query required fields, including AccountId
        List<Contact> contactsToUpdate = [SELECT Id, AccountId, Phone FROM Contact WHERE AccountId IN :accountIds];
        for (Contact con : contactsToUpdate) {
            // Update Contact's Phone using the parent Account's Phone
            con.Phone = Trigger.newMap.get(con.AccountId).Phone;
        }
        update contactsToUpdate;
    }
}

Key Features

1. Efficiency:

• Uses a Set<Id> to collect Account IDs with updated Phone fields.
• Queries only the necessary Contacts related to the updated Accounts.

• Logic:

• Updates the Phone field of Contacts by directly referencing the Trigger.newMap for the updated Account phone numbers.

• Pros:

• Simple and straightforward.
• Efficient for small to medium datasets.

• Cons:

• Uses Trigger.newMap.get(con.AccountId).Phone, which assumes that the AccountId of the Contact matches an Account in Trigger.newMap. This is generally safe but could cause issues if the data model changes.

Expected Output

WAY-2

trigger UpdateContactPhone on Account (after update) {
    // Create a map to store Account Ids and their updated Phone numbers
    Map<Id, String> accountIdToPhoneMap = new Map<Id, String>();

    // Iterate through the updated Accounts to collect those with Phone changes
    for (Account acc : Trigger.new) {
        if (acc.Phone != Trigger.oldMap.get(acc.Id).Phone) {
            accountIdToPhoneMap.put(acc.Id, acc.Phone);
        }
    }

    // If there are Accounts with updated Phone numbers, update related Contacts
    if (!accountIdToPhoneMap.isEmpty()) {
        List<Contact> contactsToUpdate = new List<Contact>();
        for (Contact con : [SELECT Id, AccountId, Phone FROM Contact WHERE AccountId IN :accountIdToPhoneMap.keySet()]) {
            // Update the Contact's Phone field with the corresponding Account's Phone
            con.Phone = accountIdToPhoneMap.get(con.AccountId);
            contactsToUpdate.add(con);
        }

        // Perform the update if there are Contacts to update
        if (!contactsToUpdate.isEmpty()) {
            update contactsToUpdate;
        }
    }
}

Key Features

1. Efficiency:

• Uses a Map<Id, String> to store Account IDs and their updated Phone numbers.
• Queries only the necessary Contacts related to the updated Accounts.

• Logic:

• Updates the Phone field of Contacts by referencing the accountIdToPhoneMap, which explicitly maps Account IDs to their updated phone numbers.

• Pros:

• More explicit and easier to debug.
• Avoids directly relying on Trigger.newMap, making it more robust to changes in the data model.

• Cons:

• Slightly more verbose due to the use of a Map.

Key Differences

 In Salesforce Apex, triggers provide context variables to access records during trigger execution. The most commonly used context variables are:

1. Trigger.new
2. Trigger.old
3. Trigger.newMap
4. Trigger.oldMap

These variables help you interact with the records being processed in the trigger. Below is an explanation of each, along with an example.

1. Trigger.new

Description

• Contains the new versions of the records being inserted or updated.
• For insert operations, it holds the new records being added.
• For update operations, it holds the updated versions of the records.

Data Type:
List<SObject> (e.g., List<Account>).

Example

trigger AccountTrigger on Account (before insert, before update) {
    for (Account acc : Trigger.new) {
        // Update the Description field for new or updated Accounts
        acc.Description = 'Updated in Trigger';
    }
}

2. Trigger.old

Description

• Contains the old versions of the records being updated or deleted.
• For update operations, it holds the records before the update.
• For delete operations, it holds the records being deleted.

Data Type:
List<SObject> (e.g., List<Account>).

Example

trigger AccountTrigger on Account (before update, before delete) {
    for (Account acc : Trigger.old) {
        // Check if the Phone field was changed during an update
        if (Trigger.isUpdate && acc.Phone != Trigger.newMap.get(acc.Id).Phone) {
            System.debug('Phone field was updated for Account: ' + acc.Id);
        }
    }
}

3. Trigger.newMap

Description

• Contains the new versions of the records being inserted or updated, but in a map format.
• The map key is the record ID, and the value is the record itself.
• Useful for quickly accessing records by their ID.

Data Type:
Map<Id, SObject> (e.g., Map<Id, Account>).

Example

trigger AccountTrigger on Account (after update) {
    for (Id accId : Trigger.newMap.keySet()) {
        Account newAcc = Trigger.newMap.get(accId);
        Account oldAcc = Trigger.oldMap.get(accId);
        // Check if the Name field was changed
        if (newAcc.Name != oldAcc.Name) {
            System.debug('Name field was updated for Account: ' + newAcc.Id);
        }
    }
}

4. Trigger.oldMap

Description

• Contains the old versions of the records being updated or deleted, but in a map format.
• The map key is the record ID, and the value is the record itself.
• Useful for quickly accessing the old versions of records by their ID.

Data Type:
Map<Id, SObject> (e.g., Map<Id, Account>).

Example

trigger AccountTrigger on Account (after update) {
    for (Id accId : Trigger.oldMap.keySet()) {
        Account oldAcc = Trigger.oldMap.get(accId);
        Account newAcc = Trigger.newMap.get(accId);
        // Check if the Industry field was changed
        if (oldAcc.Industry != newAcc.Industry) {
            System.debug('Industry field was updated for Account: ' + oldAcc.Id);
        }
    }
}

Key Differences

Example Scenario

Let’s say you want to track changes to the Phone field on the Account object and log a message if the Phone field is updated.

trigger AccountTrigger on Account (before update, after update) {
    if (Trigger.isBefore && Trigger.isUpdate) {
        // Use Trigger.new and Trigger.old in before update
        for (Account newAcc : Trigger.new) {
            Account oldAcc = Trigger.oldMap.get(newAcc.Id);
            if (newAcc.Phone != oldAcc.Phone) {
                System.debug('Phone field will be updated for Account: ' + newAcc.Id);
            }
        }
    }

    if (Trigger.isAfter && Trigger.isUpdate) {
        // Use Trigger.newMap and Trigger.oldMap in after update
        for (Id accId : Trigger.newMap.keySet()) {
            Account newAcc = Trigger.newMap.get(accId);
            Account oldAcc = Trigger.oldMap.get(accId);
            if (newAcc.Phone != oldAcc.Phone) {
                System.debug('Phone field was updated for Account: ' + accId);
            }
        }
    }
}

Explanation of the Example

1. Before Update:

• Uses Trigger.new and Trigger.oldMap to compare the old and new values of the Phone field.
• Logs a message if the Phone field is about to be updated.

• After Update:

• Uses Trigger.newMap and Trigger.oldMap to compare the old and new values of the Phone field.
• Logs a message if the Phone field was updated.

Expected Output

The debug logs will show the values of Phone before and after the update.

When to Use Each

• Use Trigger.new and Trigger.old when you need to iterate through records in a list.
• Use Trigger.newMap and Trigger.oldMap when you need to quickly access records by their ID or compare old and new values efficiently.

 Below is the Apex trigger that updates the Hired_Date__c field with the current date and time whenever a Candidate__c record's Status__c is updated to "Hired". The trigger is bulkified to handle multiple records being updated at once.

Trigger Code: CandidateTrigger.apxt

trigger CandidateTrigger on Candidate__c (before update) {
    // Create a list to store Candidates whose Status is updated to "Hired"
    List<Candidate__c> candidatesToUpdate = new List<Candidate__c>();

    // Iterate through the updated Candidates
    for (Candidate__c newCandidate : Trigger.new) {
        // Get the old version of the Candidate record
        Candidate__c oldCandidate = Trigger.oldMap.get(newCandidate.Id);

        // Check if the Status__c field is updated to "Hired"
        if (newCandidate.Status__c == 'Hired' && newCandidate.Status__c != oldCandidate.Status__c) {
            // Update the Hired_Date__c field with the current date and time
            newCandidate.Hired_Date__c = DateTime.now();
            candidatesToUpdate.add(newCandidate);
        }
    }

    // Log the number of Candidates being updated
    if (!candidatesToUpdate.isEmpty()) {
        System.debug('Number of Candidates updated to "Hired": ' + candidatesToUpdate.size());
    }
}

Explanation of the Code

1. Bulkification:

• The trigger processes multiple Candidate__c records in a single transaction using a loop (for (Candidate__c newCandidate : Trigger.new)).
• It avoids querying inside the loop, which is a best practice for bulkification.

• Efficiency:

• It only updates the Hired_Date__c field if the Status__c field is changed to "Hired".
• It uses Trigger.oldMap to compare the old and new values of the Status__c field, ensuring unnecessary updates are avoided.

• Logging:

• It logs the number of Candidates being updated for debugging purposes.

Example Input and Output

Input

Assume the following Candidate__c records are being updated in a single transaction:

Update the Status__c field for:

• John Doe: "Applied" ---> "Hired"
• Jane Smith: "Interviewed" ---> "Hired"
• Alice Brown: "Hired" ---> "Hired" (no change)
• Bob Johnson: "Applied" ---> "Interviewed"

Output

After the trigger runs:

• The Hired_Date__c field is updated for John Doe and Jane Smith because their Status__c was changed to "Hired".
• Alice Brown's Hired_Date__c remains unchanged because her Status__c was already "Hired".
• Bob Johnson's Hired_Date__c remains unchanged because his Status__c was not updated to "Hired".

Updated records:

Debug Log

Number of Candidates updated to "Hired": 2

• Conditional Logic:

• It only updates records where the Status__c field is changed to "Hired", avoiding unnecessary updates.

• Use of Context Variables:

• It uses Trigger.new and Trigger.oldMap to compare old and new values of the Status__c field.

• Logging:

• It logs the number of records being updated for debugging and monitoring purposes.

 Below is the Apex trigger that updates the Rating field of an Account to "Hot" if it has more than 10 related Opportunities. The trigger is designed to respect governor limits and handle bulk updates efficiently.

UpdateAccountRating.apxt

trigger UpdateAccountRating on Opportunity (after insert, after update) {

    // Step 1: Collect Account IDs related to the new or updated opportunities
    Set<Id> accountIds = new Set<Id>();
    for (Opportunity opp : Trigger.new) {
        if (opp.AccountId != null) { // Ensure the opportunity has an associated Account
            accountIds.add(opp.AccountId);
        }
    }

    // Step 2: Query the count of related opportunities for each Account
    Map<Id, Integer> accountOppCountMap = new Map<Id, Integer>();
    for (AggregateResult ar : [SELECT AccountId, COUNT(Id) oppCount 
                                FROM Opportunity 
                                WHERE AccountId IN :accountIds 
                                GROUP BY AccountId]) {
        // Store the AccountId and the count of related opportunities in a map
        accountOppCountMap.put((Id) ar.get('AccountId'), (Integer) ar.get('oppCount'));
    }

    // Step 3: Prepare a list of Account records to update
    List<Account> accountsToUpdate = new List<Account>();
    for (Id accId : accountOppCountMap.keySet()) {
        // Check if the number of opportunities exceeds 10
        if (accountOppCountMap.get(accId) > 10) {
            // Create an Account record with updated Rating and add to the list
            accountsToUpdate.add(new Account(Id = accId, Rating = 'Hot'));
        }
    }

    // Step 4: Update the Accounts if there are any to process
    if (!accountsToUpdate.isEmpty()) {
        try {
            update accountsToUpdate; // Perform a single DML operation for efficiency
        } catch (DmlException e) {
            System.debug('Error updating Account ratings: ' + e.getMessage());
        }
    }
}

Explanation of the Code

1. Bulkification:

• The trigger handles multiple Opportunity records in a single transaction.
• A Set<Id> is used to collect unique AccountIds to minimize processing.
• An aggregate query with GROUP BY efficiently counts related Opportunities for each Account.

• Efficiency:

• Only Accounts with more than 10 related Opportunities are updated.
• The trigger performs a single update operation, respecting Salesforce governor limits.

• Governor Limits Handling:

• Efficient SOQL query (GROUP BY) minimizes the number of queries.
• A single DML operation (update accountsToUpdate) ensures compliance with governor limits.

• Use Case:

• Automatically updates the Rating of an Account to "Hot" when it has more than 10 related Opportunities.

Example Scenario

• An Account has 12 related Opportunities.
• When a new Opportunity is added, the trigger evaluates the total count.
• If the count exceeds 10, the trigger updates the Rating field of the Account to "Hot".

 Below is the Apex trigger that makes an asynchronous call to update a related Account record whenever a Case is closed. The trigger uses a @future method to ensure the update is performed asynchronously.

AccountUpdateService.apxc

public class AccountUpdateService {
    @future
    public static void updateAccountsAsync(Set<Id> accountIds) {
        List<Account> accountsToUpdate = new List<Account>();
        for (Id accId : accountIds) {
            // Update a custom field on the Account (e.g., Last_Case_Closed_Date__c)
            accountsToUpdate.add(new Account(Id = accId, Last_Case_Closed_Date__c = Date.today()));
        }

        // Perform the update
        if (!accountsToUpdate.isEmpty()) {
            update accountsToUpdate;
        }
    }
}

Trigger Code: CaseTrigger.apxt

The trigger to call the updateAccountsAsync method from the AccountUpdateService class.

trigger CaseTrigger on Case (after update) {
    // Collect Account IDs for Cases that are closed
    Set<Id> accountIds = new Set<Id>();
    for (Case cs : Trigger.new) {
        if (cs.Status == 'Closed' && Trigger.oldMap.get(cs.Id).Status != 'Closed') {
            accountIds.add(cs.AccountId);
        }
    }

    // Call the future method to update related Accounts
    if (!accountIds.isEmpty()) {
        AccountUpdateService.updateAccountsAsync(accountIds);
    }
}

Explanation of the Code

1. Trigger Logic:

• The trigger runs after update on the Case object.
• It collects AccountIds for Cases that are being closed (Status changed to "Closed").

• Asynchronous Update:

• A @future method (updateAccountsAsync) is used to update the related Account records asynchronously.
• This ensures that the update does not block the Case closure process.

• Bulk-Friendly:

• The trigger handles multiple Cases being closed in a single transaction.
• The @future method processes the updates in bulk.

• Use Case:

• This trigger updates a custom field (Last_Case_Closed_Date__c) on the related Account whenever a Case is closed.

How It Works

1. When a Case is closed, the trigger collects the AccountId of the related Account.
2. The trigger calls the updateAccountsAsync method, passing the AccountIds as a parameter.
3. The @future method updates the Last_Case_Closed_Date__c field on the related Accounts asynchronously.

Example Scenario

• A Case is closed, and its AccountId is 001XXXXXXXXXXXX.
• The trigger calls the @future method, which updates the Last_Case_Closed_Date__c field on the related Account to today's date.

Key Points

• Asynchronous Processing: The @future method ensures that the update is performed asynchronously, improving performance and avoiding governor limits.
• Bulkification: The trigger and @future method are designed to handle multiple records efficiently.
• Use of Context Variables: The trigger uses Trigger.new and Trigger.oldMap to detect changes in the Status field.

 Below is the Apex trigger that creates a Case record automatically whenever a new Contact is inserted. The Case's Subject will be set to "Welcome Case for [Contact Name]".

Object : Contact
Trigger: after insert

Trigger Code: CreateCaseOnContactInsert.apxt

trigger CreateCaseOnContactInsert on Contact (after insert) {
    List<case> caseList = new List<Case>();  // List to hold new Case records

    for (Contact con : Trigger.new) {
        Case welcomeCase = new Case(
            Subject = 'Welcome Case for ' + con.FirstName + ' ' + con.LastName,
            ContactId = con.Id,
            Status = 'New',  // Default status, can be customized
            Origin = 'Web'   // Default origin, can be customized
        );
        caseList.add(welcomeCase);
    }

    if (!caseList.isEmpty()) {
        insert caseList;  // Insert all new Case records
    }
}

Explanation

1. Trigger Event:
The trigger runs after insert because the Contact ID is needed to associate the new Case with the Contact.

2. Loop Through Trigger Records:
The for loop iterates over each Contact in the Trigger.new list (records being inserted).

3. Case Creation:
A new Case is created for each Contact with:

• Subject: "Welcome Case for [Contact Name]"
• ContactId: Associated with the newly inserted Contact.
• Status: Set to "New" (you can customize this based on business needs).
• Origin: Set to "Web" (default value, can be changed).

4. Bulk Handling:
The code uses a list (caseList) to store the new Case records and inserts them in bulk to avoid governor limits.

Output:
When a new Contact is inserted, the following outcomes are expected:

• A new Case record will be automatically created for each Contact.
• The Subject of the Case will be:

"Welcome Case for [Contact FirstName] [Contact LastName]"

 Salesforce does not guarantee the execution order of triggers when you have multiple triggers on the same object and event. To ensure a specific execution order, you should use a trigger handler pattern where both triggers delegate their logic to a common handler class. This way, you can control the sequence in which the logic is executed.

Real Example

Let's say you have two triggers on the Account object:

1. Trigger A (updates Account.Status__c)
2. Trigger B (sends an email notification when Account.Status__c changes)

To ensure Trigger A executes before Trigger B, both triggers will call a handler class in a specified order.

Step-by-Step Solution

1. Create a Trigger Handler Class: Define a class that contains the logic for both actions (updating the Status__c field and sending an email).

// apex
public class AccountTriggerHandler {
    
    public static void handleBeforeUpdate(List<Account> oldAccounts, List<Account> newAccounts) {
        // Step 1: Execute Trigger A logic (update Status__c)
        updateAccountStatus(oldAccounts, newAccounts);
        
        // Step 2: Execute Trigger B logic (send email if Status__c changes)
        sendEmailNotification(oldAccounts, newAccounts);
    }
    
    private static void updateAccountStatus(List<Account> oldAccounts, List<Account> newAccounts) {
        for (Account acc : newAccounts) {
            if (/* condition to update Status__c */) {
                acc.Status__c = 'Updated Status';
            }
        }
    }
    
    private static void sendEmailNotification(List<Account> oldAccounts, List<Account> newAccounts) {
        for (Integer i = 0; i < newAccounts.size(); i++) {
            if (oldAccounts[i].Status__c != newAccounts[i].Status__c) {
                // Logic to send email
                Messaging.SingleEmailMessage email = new Messaging.SingleEmailMessage();
                email.setSubject('Account Status Changed');
                email.setToAddresses(new String[] { 'user@example.com' });
                email.setPlainTextBody('The Account Status has been changed.');
                Messaging.sendEmail(new Messaging.SingleEmailMessage[] { email });
            }
        }
    }
}

2. Modify Both Triggers to Use the Handler Class: Instead of having the logic inside the trigger, both triggers will simply delegate the logic to the handler class.

• Trigger A:

trigger AccountTriggerA on Account (before update) {
    AccountTriggerHandler.handleBeforeUpdate(Trigger.old, Trigger.new);
}

trigger AccountTriggerB on Account (before update) {
    AccountTriggerHandler.handleBeforeUpdate(Trigger.old, Trigger.new);
}

Key Points

• Single Entry Point: Both triggers now delegate their logic to the AccountTriggerHandler class, which acts as the single entry point for handling all logic.
• Order of Execution: Inside the handler class, the logic for updating the Status__c field (Trigger A's logic) is executed before sending the email (Trigger B's logic). This ensures that Trigger A's logic always runs before Trigger B's, even though both triggers are on the same object and event.

Benefits of This Approach

1. Controlled Execution: You have full control over the execution order.
2. Maintainability: Centralizing the logic in a handler class makes it easier to maintain and debug.
3. Best Practices: Using handler classes is a best practice in Salesforce development, especially when dealing with complex trigger logic.

Example Condition

In the example I provided, CustomStatus__c is assumed to be a Text or Picklist field, as these are common data types for status-related fields.

Let’s say you want to update the CustomStatus__c field if the Account Industry changes to Technology.

Here's how you could implement the condition:

//apex
public class AccountTriggerHandler {

    // Method to handle before update logic
    public static void handleBeforeUpdate(List<Account> oldAccounts, List<Account> newAccounts) {
        // Step 1: Execute Trigger A logic (update CustomStatus__c)
        updateAccountStatus(oldAccounts, newAccounts);
        
        // Step 2: Execute Trigger B logic (send email if Industry changes to 'Technology')
        sendEmailNotification(oldAccounts, newAccounts);
    }
    
    // Method to update the CustomStatus__c field based on Industry change
    private static void updateAccountStatus(List<Account> oldAccounts, List<Account> newAccounts) {
        for (Integer i = 0; i < newAccounts.size(); i++) {
            Account oldAcc = oldAccounts[i];
            Account newAcc = newAccounts[i];
            
            // Condition: Update CustomStatus__c if Industry changes to 'Technology'
            if (oldAcc.Industry != newAcc.Industry && newAcc.Industry == 'Technology') {
                newAcc.CustomStatus__c = 'Updated for Tech Industry';
            }
        }
    }
    
    // Method to send email notification when Industry changes to 'Technology'
    private static void sendEmailNotification(List<Account> oldAccounts, List<Account> newAccounts) {
        List<messaging.singleemailmessage> emailsToSend = new List<messaging.singleemailmessage>();
        
        for (Integer i = 0; i < newAccounts.size(); i++) {
            Account oldAcc = oldAccounts[i];
            Account newAcc = newAccounts[i];
            
            // Check if Industry has changed to 'Technology'
            if (oldAcc.Industry != newAcc.Industry && newAcc.Industry == 'Technology') {
                // Create the email message
                Messaging.SingleEmailMessage email = new Messaging.SingleEmailMessage();
                
                // Set the email properties
                email.setSubject('Account Status Updated');
                email.setToAddresses(new String[] { 'user@example.com' }); // Change to actual email address
                email.setPlainTextBody('The Account Industry has been changed to Technology. The status has been updated.');
                
                // Add the email to the list
                emailsToSend.add(email);
            }
        }
        
        // Send all emails at once
        if (!emailsToSend.isEmpty()) {
            Messaging.sendEmail(emailsToSend);
        }
    }
}

Explanation

1. handleBeforeUpdate:

• This method first calls updateAccountStatus() to update the CustomStatus__c field if the Industry changes to 'Technology'.
• Then it calls sendEmailNotification() to send an email notification if the Industry changes.

• updateAccountStatus:

• This method checks if the Industry field has changed from the old value to 'Technology'. If so, it updates the CustomStatus__c field.

• sendEmailNotification:

• This method sends an email if the Industry changes to 'Technology'. It creates a list of email messages and sends them at once using Messaging.sendEmail().
• The email subject and body can be customized as needed. In this example, it's a simple notification that the Account Industry was changed.

Trigger Code

trigger AccountTriggerA on Account (before update) {
    AccountTriggerHandler.handleBeforeUpdate(Trigger.old, Trigger.new);
}

How it Works

• Account Update: When you update an Account and change the Industry field to Technology, the trigger will fire.
• CustomStatus__c Update: If the Industry changes to Technology, the CustomStatus__c field will be updated.
• Email Notification: An email will be sent to the specified address notifying that the Industry has been updated.

You can modify the email content and recipient email addresses as needed for your specific use case.

Email Notification Output

 Since we’re dealing with the Account and Invoice standard objects, where Invoice has a lookup relationship to Account through the Billing Account field, we can’t use a roll-up summary field directly. Instead, we can use an Apex trigger to calculate the total TotalAmount of all Invoice records related to an Account and update a custom field, TotalAmount__c, on the Account object.

Object : Invoice
Trigger: after insert, after update, after delete, after undelete

Trigger Code: InvoiceRollupTrigger.apxt

trigger InvoiceRollupTrigger on Invoice (after insert, after update, after delete, after undelete) {
    
    // Step 1: Identify the Account IDs needing recalculation
    Set<Id> accountIds = new Set<Id>();
    
    // Collect relevant Account IDs based on trigger events
    if (Trigger.isInsert || Trigger.isUndelete) {
        for (Invoice inv : Trigger.new) {
            accountIds.add(inv.BillingAccountId);
        }
    }
    if (Trigger.isUpdate) {
        for (Invoice inv : Trigger.new) {
            accountIds.add(inv.BillingAccountId);
        }
        for (Invoice oldInv : Trigger.old) {
            accountIds.add(oldInv.BillingAccountId);
        }
    }
    if (Trigger.isDelete) {
        for (Invoice inv : Trigger.old) {
            accountIds.add(inv.BillingAccountId);
        }
    }
    
    // Step 2: Aggregate query to calculate the total of TotalAmount on Invoice
    Map<Id, Decimal> accountInvoiceTotals = new Map<Id, Decimal>();
    for (AggregateResult ar : [
        SELECT BillingAccountId, SUM(TotalAmount) totalAmount
        FROM Invoice
        WHERE BillingAccountId IN :accountIds
        GROUP BY BillingAccountId
    ]) {
        accountInvoiceTotals.put((Id)ar.get('BillingAccountId'), (Decimal)ar.get('totalAmount'));
    }
    
    // Step 3: Prepare Account records for update with recalculated TotalAmount__c
    List<Account> accountsToUpdate = new List<Account>();
    for (Id accountId : accountIds) {
        Account accountToUpdate = new Account(Id = accountId);
        accountToUpdate.TotalAmount__c = accountInvoiceTotals.containsKey(accountId) ? accountInvoiceTotals.get(accountId) : 0;
        accountsToUpdate.add(accountToUpdate);
    }
    
    // Step 4: Update Account records with the calculated TotalAmount__c
    if (!accountsToUpdate.isEmpty()) {
        update accountsToUpdate;
    }
}

Explanation

1. Identify Relevant Account IDs: The trigger gathers all Account IDs where recalculations are needed, accounting for insert, update, delete, and undelete trigger events. This ensures we capture any changes that could affect the TotalAmount__c on the Account.
2. Aggregate Query for Total Calculation: We use an SOQL aggregate query to calculate the sum of TotalAmount from Invoice records for each Billing Account. The results are stored in a map where the Account ID is the key and the calculated total is the value.
3. Prepare Account Updates: We create a list of Account records to update. For each Account ID, we set TotalAmount__c to the calculated sum or, if no Invoices are associated with that Account, we set it to 0.
4. Update Accounts: Finally, we update the Account records with the calculated totals.

Example Scenario and Output

Consider the following Invoice data:

1. Inserting Inv4 with Billing Account = Acc1 and TotalAmount = 50:

• The trigger will calculate the new total for Acc1 as: 100 + 200 + 50 = 350
• Therefore, the updated TotalAmount__c on Acc1 will be 350.

• Updating Inv2 for Acc1 from 200 to 300:

• The trigger recalculates Acc1.
• Updated TotalAmount__c for Acc1 = 100 + 300 + 50 = 450.

• Deleting Inv1 for Acc1:

• The trigger recalculates Acc1.
• New TotalAmount__c for Acc1 = 300 + 50 = 350.

Final Output

After these actions, the TotalAmount__c field values on the Account records would be:

Key Concepts Tested

• Custom Roll-Up Summary with Apex Trigger: This solution shows how to use triggers to create roll-up summaries for lookup relationships.
• SOQL Aggregate Queries: Leveraging aggregate functions in SOQL to efficiently retrieve and sum data.
• Trigger Contexts: Managing insert, update, delete, and undelete events to ensure calculations are accurate in all scenarios.

This solution demonstrates my understanding of implementing a custom roll-up summary on standard objects with a lookup relationship.

 To update the Last_Contact_Date__c field on the Account when a new Contact is inserted, I would create an after insert trigger on the Contact object. An after insert trigger is appropriate in this case because the Contact record must be inserted first to obtain its AccountId.

Implementation Steps

1. Collect all AccountId values from the inserted Contacts to identify the related parent Accounts.
2. Use a Map to store each AccountId and the latest CreatedDate of its Contacts.
3. Query the necessary Account records and update the Last_Contact_Date__c field based on the latest contact creation date.
4. Use a single DML operation to update the Account records to follow bulk processing best practices.

Here is an example trigger code for the scenario

Object : Contact
Trigger: after insert

Trigger Code: UpdateAccountLastContactDate.apxt

trigger UpdateAccountLastContactDate on Contact (after insert) {
    // Step 1: Create a Map to store AccountId and the latest contact creation date
    Map<Id, Date> accountToLastContactDateMap = new Map<Id, Date>();
    
    // Step 2: Loop through inserted contacts and populate the map with the latest date
    for (Contact con : Trigger.new) {
        if (con.AccountId != null) {
            Date contactDate = con.CreatedDate.date(); // Convert CreatedDate to Date
            Date lastContactDate = accountToLastContactDateMap.get(con.AccountId);
            if (lastContactDate == null || contactDate > lastContactDate) {
                accountToLastContactDateMap.put(con.AccountId, contactDate);
            }
        }
    }
    
    // Step 3: Query Accounts and update the Last_Contact_Date__c field
    List<Account> accountsToUpdate = new List<Account>();
    for (Id accountId : accountToLastContactDateMap.keySet()) {
        Account acc = new Account(Id = accountId, Last_Contact_Date__c = accountToLastContactDateMap.get(accountId));
        accountsToUpdate.add(acc);
    }
    
    // Step 4: Perform a single update DML for all accounts
    if (!accountsToUpdate.isEmpty()) {
        update accountsToUpdate;
    }
}

Explanation

• Trigger Context: This trigger is an after insert since we need access to the AccountId of the newly created Contacts.
• Map for Bulk Handling: The Map helps handle bulk inserts effectively by storing the most recent Contact creation date for each Account.
• Single DML Operation: Only one update statement is used to ensure we don’t exceed DML governor limits.

Expected Output

When multiple Contacts are inserted for different Accounts, the Last_Contact_Date__c on each related Account will reflect the most recent Contact creation date.

For example, if Contact1 (CreatedDate: 2024-11-01) and Contact2 (CreatedDate: 2024-11-05) are inserted for Account A, then the Last_Contact_Date__c on Account A will be set to 2024-11-05.

Here Contact2 (Mr. Jack Jhon) (CreatedDate: 2024-11-05)

Last Contact Date on Account A will be set to 2024-11-05.

Why This Approach?

This approach is designed to ensure scalability and adherence to Salesforce best practices, especially for handling bulk data and minimizing DML usage.

 To implement a trigger that automatically updates the StageName of an Opportunity to "Closed Won" when all related Tasks are marked as "Completed", I would create an after update trigger on the Task object. This approach ensures that we detect Task status changes and check if all Tasks related to the parent Opportunity are completed before updating the Opportunity.

Implementation Steps

1. Collect Opportunity IDs: Identify the parent Opportunities for all updated Tasks.
2. Check Task Status: Use SOQL to query and determine whether each Opportunity's Tasks are all marked as "Completed".
3. Update Opportunity Stage: For Opportunities where all Tasks are completed, set StageName to "Closed Won" and perform a single update DML operation.

Here is an example trigger code for the scenario

Object : Task
Trigger: after update

Trigger Code: AutoCloseOpportunities.apxt

trigger AutoCloseOpportunities on Task (after update) {
    
    // Step 1: Collect Opportunity IDs for the related tasks that have changed to "Completed"
    Set<Id> opportunityIds = new Set<Id>();
    
    for (Task t : Trigger.new) {
        if (t.Status == 'Completed' && t.WhatId != null && t.WhatId.getSObjectType() == Opportunity.SObjectType) {
            opportunityIds.add(t.WhatId);
        }
    }
    
    if (opportunityIds.isEmpty()) {
        return; // Exit if no relevant opportunities
    }
    
    // Step 2: Query all tasks related to these opportunities to check their statuses
    Map<Id, Boolean> oppIdToAllTasksCompleted = new Map<Id, Boolean>();
    
    for (AggregateResult ar : [
        SELECT WhatId Id, MIN(Status) status
        FROM Task
        WHERE WhatId IN :opportunityIds
        GROUP BY WhatId
    ]) {
        String minStatus = (String) ar.get('status');
        oppIdToAllTasksCompleted.put((Id) ar.get('Id'), minStatus == 'Completed');
    }
    
    // Step 3: Prepare Opportunities for update where all tasks are completed
    List<Opportunity> opportunitiesToUpdate = new List<Opportunity>();
    
    for (Id oppId : oppIdToAllTasksCompleted.keySet()) {
        if (oppIdToAllTasksCompleted.get(oppId)) {
            opportunitiesToUpdate.add(new Opportunity(Id = oppId, StageName = 'Closed Won'));
        }
    }
    
    // Step 4: Perform a single DML update
    if (!opportunitiesToUpdate.isEmpty()) {
        update opportunitiesToUpdate;
    }
}

Explanation

• Trigger Context: This after update trigger on Task allows us to check if any Task related to an Opportunity has been updated to "Completed".
• Set Collection for Bulk Processing: We use a Set<Id> to gather Opportunity IDs, handling multiple Tasks and Opportunities in one transaction.
• Aggregate Query for Efficiency: The SOQL aggregate query with MIN(Status) checks if any Task has a status other than "Completed". If all Tasks are completed, MIN(Status) will return "Completed", allowing us to update the Opportunity.
• Single DML Update: Using one update statement on the Opportunity records adheres to best practices and avoids exceeding governor limits.

Output

When the last open Task for an Opportunity is marked "Completed", the trigger automatically updates the StageName of that Opportunity to "Closed Won". For instance, if Opportunity A has three related Tasks and the last one is completed, Opportunity A’s StageName will be updated to "Closed Won".

Why This Approach?

This solution is efficient, scalable, and follows best practices for bulk processing. By using aggregate queries and single DML operations, it ensures that the solution can handle large data volumes within Salesforce governor limits.

 To implement a trigger that prevents the creation or update of Opportunities with duplicate Names under the same Account, I would start by identifying opportunities in bulk to handle potential duplicates efficiently. I would use a before insert and before update trigger to detect duplicate names within the same account and add an error message if a duplicate is found. This approach also ensures we meet Salesforce best practices for handling bulk data and minimizing database queries.

Here is an example trigger code for the scenario

Object : Opportunity
Trigger: before insert, before update

Trigger Code: PreventDuplicateOpportunityName.apxt

trigger PreventDuplicateOpportunityName on Opportunity (before insert, before update) {
    
    // Collect Account IDs for all Opportunities being processed
    Set<Id> accountIds = new Set<Id>();
    
    for (Opportunity opp : Trigger.new) {
        if (opp.AccountId != null) {
            accountIds.add(opp.AccountId);
        }
    }

    // Retrieve all existing Opportunities for the relevant Accounts
    Map<Id, Set<String>> accountOppNamesMap = new Map<Id, Set<String>>();
    
    for (Opportunity existingOpp : [SELECT Id, Name, AccountId FROM Opportunity WHERE AccountId IN :accountIds]) {
        if (!accountOppNamesMap.containsKey(existingOpp.AccountId)) {
            accountOppNamesMap.put(existingOpp.AccountId, new Set<String>());
        }
        accountOppNamesMap.get(existingOpp.AccountId).add(existingOpp.Name);
    }

    // Check each new or updated Opportunity for duplicates within the same Account
    for (Opportunity opp : Trigger.new) {
        if (opp.AccountId != null) {
            Set<String> existingOppNames = accountOppNamesMap.get(opp.AccountId);
            if (existingOppNames != null && existingOppNames.contains(opp.Name)) {
                // Prevent update for existing record or new insertion with duplicate name
                if (Trigger.isInsert || (Trigger.isUpdate && Trigger.oldMap.get(opp.Id).Name != opp.Name)) {
                    opp.addError('An Opportunity with this Name already exists for this Account.');
                }
            } else {
                // Add new Opportunity name to the map to prevent intra-trigger duplicates
                if (!accountOppNamesMap.containsKey(opp.AccountId)) {
                    accountOppNamesMap.put(opp.AccountId, new Set<String>());
                }
                accountOppNamesMap.get(opp.AccountId).add(opp.Name);
            }
        }
    }
}

Explanation

1. Collect Account IDs: First, I gather all Account IDs from the Opportunities being processed to avoid duplicates within these accounts.
2. Query Existing Opportunities: I retrieve existing Opportunities for those Accounts, storing each Account’s Opportunity names in a Map<Id, Set<String>> structure. This allows for fast lookups of existing names.
3. Validate Each Opportunity: For each Opportunity in Trigger.new, I check if its name already exists in the Set of names for that Account. If it’s a duplicate (and not just a renaming of the same Opportunity), I use addError() to prevent the insertion or update.
4. Add New Names to Map: To handle bulk inserts or updates where multiple Opportunities for the same Account might be processed, I add each new Opportunity name to the Map to ensure all names remain unique within the trigger execution context.

Output

If a user tries to create or update an Opportunity with a duplicate name under the same Account, they will see the following error:

• Error Message: "An Opportunity with this Name already exists for this Account."

This error prevents the operation and helps maintain data integrity by enforcing uniqueness for Opportunity names within each Account.

Why This Approach?

This implementation ensures that the trigger:

• Handles bulk operations effectively, as it prevents unnecessary SOQL queries in the loop and uses collections for quick lookups.
• Meets best practices for governor limits by querying only once per set of Accounts.
• Provides clear, actionable feedback to the user by using addError() to highlight the duplicate issue.

 To solve this, I'll create an after insert and after update trigger on the Contact object. The trigger will evaluate whether any Contact associated with an Account has the title "CEO." If so, it will set the parent Account’s Industry field to "Executive Services." Here’s how I’d implement it:

Solution Approach

1. Use an after trigger because we need the Contact records to be committed to the database before updating the related Account.
2. Collect all Account IDs related to the newly inserted or updated Contacts.
3. Query the Accounts and their related Contacts to see if any of the Contacts have the title "CEO."
4. Update the Industry field on the Account to "Executive Services" if a "CEO" title exists.

Example Code

Here’s how I would implement this trigger:

Object : Contact
Trigger: after insert, after update

Trigger Code: UpdateAccountIndustryBasedOnContactTitle.apxt

trigger UpdateAccountIndustryBasedOnContactTitle on Contact (after insert, after update) {
    // Step 1: Collect Account IDs
    Set<Id> accountIds = new Set<Id>();
    
    for (Contact con : Trigger.new) {
        if (con.AccountId != null) {
            accountIds.add(con.AccountId);
        }
    }
    
    // Step 2: Query related Accounts and Contacts
    List<Account> accountsToUpdate = new List<Account>();
    
    Map<Id, Account> accountMap = new Map<Id, Account>([SELECT Id, Industry, (SELECT Title FROM Contacts)
                                                        FROM Account
                                                        WHERE Id IN :accountIds]);
    
    // Step 3: Determine if Industry should be updated
    for (Account acc : accountMap.values()) {
        Boolean hasCEO = false;
        for (Contact con : acc.Contacts) {
            if (con.Title == 'CEO') {
                hasCEO = true;
                break;
            }
        }
        
        if (hasCEO && acc.Industry != 'Executive Services') {
            acc.Industry = 'Executive Services';
            accountsToUpdate.add(acc);
        }
    }
    
    // Step 4: Update Accounts
    if (!accountsToUpdate.isEmpty()) {
        try {
            update accountsToUpdate;
        } catch (DmlException e) {
            System.debug('Error updating Accounts: ' + e.getMessage());
        }
    }
}

Explanation

1. Collect Account IDs: In the first loop, I gather AccountId values from each Contact. This ensures we only process related Accounts.
2. Query Accounts and Related Contacts: We retrieve Accounts and their Contacts in a single query to avoid additional database queries (helps prevent SOQL limit issues).
3. Check for "CEO" Title: For each Account’s Contacts, we check if any Contact has the title "CEO." If found, we update that Account’s Industry to "Executive Services."
4. Update Accounts: After identifying which Accounts need updates, we perform a bulk update to ensure efficiency.

Output

If a Contact with the title "CEO" is added or updated, the Industry field on the related Account will be set to "Executive Services." If the Industry is already "Executive Services," no change is made to avoid unnecessary updates.

This approach ensures performance, scalability, and correctness in updating Accounts based on related Contacts.

 To implement this scenario, I would create an after update trigger on the Opportunity object. This ensures that we can identify when the StageName changes to "Negotiation/Review" and send an email notification to the Opportunity Owner.

Solution Approach

1. Use an after update trigger: Since we need to send an email after the record has been updated, we use the after update event.
2. Track field changes: Compare the StageName in Trigger.new with the previous value in Trigger.oldMap to identify records that have moved to the "Negotiation/Review" stage.
3. Prepare email notifications: Use the Messaging.SingleEmailMessage class to send emails to the Opportunity Owners.
4. Bulkify the solution: Ensure the trigger handles multiple records efficiently without exceeding governor limits.

Example Code:
Here’s how I would implement this trigger:

Object : Opportunity
Trigger: after update

Trigger Code: NotifyOnNegotiationStage.apxt

trigger NotifyOnNegotiationStage on Opportunity (after update) {
    
    // Step 1: Collect Opportunity IDs where StageName has changed to "Negotiation/Review"
    Map<Id, Id> oppIdToOwnerIdMap = new Map<Id, Id>(); // OpportunityId -> OwnerId

    for (Opportunity opp : Trigger.new) {
        if (opp.StageName == 'Negotiation/Review' && 
            Trigger.oldMap.get(opp.Id).StageName != 'Negotiation/Review') {
            oppIdToOwnerIdMap.put(opp.Id, opp.OwnerId);
        }
    }

    if (!oppIdToOwnerIdMap.isEmpty()) {
        
        // Step 2: Query Users for email addresses
        Map<Id, String> ownerEmails = new Map<id, String>();
        for (User owner : [SELECT Id, Email FROM User WHERE Id IN :oppIdToOwnerIdMap.values()]) {
            ownerEmails.put(owner.Id, owner.Email);
        }

        // Step 3: Create email messages
        List<Messaging.SingleEmailMessage> emailMessages = new List<Messaging.SingleEmailMessage>();
        for (Id oppId : oppIdToOwnerIdMap.keySet()) {
            Id ownerId = oppIdToOwnerIdMap.get(oppId);
            String ownerEmail = ownerEmails.get(ownerId);

            if (ownerEmail != null) {
                Messaging.SingleEmailMessage email = new Messaging.SingleEmailMessage();
                email.setToAddresses(new List<String>{ownerEmail});
                email.setSubject('Opportunity Moved to Negotiation/Review');
                email.setPlainTextBody('Your Opportunity has been moved to the Negotiation/Review stage. Please take the necessary actions.');
                emailMessages.add(email);
            }
        }

        // Step 4: Send emails
        if (!emailMessages.isEmpty()) {
            Messaging.sendEmail(emailMessages);
        }
    }
}

Explanation of the Code

1. Track field changes: The trigger compares Trigger.new and Trigger.oldMap to identify records where StageName has changed to "Negotiation/Review."
2. Query email addresses: After identifying the Opportunity Owners, their email addresses are queried to avoid hardcoding.
3. Compose email notifications: A Messaging.SingleEmailMessage object is created for each owner with a subject and body text.
4. Bulkify the trigger: The trigger is optimized for bulk processing by:
5. • Using collections like Map and Set for efficient queries.
   • Sending all emails in a single transaction to reduce DML operations.

Output

1. Scenario 1: If an Opportunity's StageName changes to "Negotiation/Review":

• An email notification is sent to the Opportunity Owner with the subject: "Opportunity Moved to Negotiation/Review."
• The body contains a message prompting the owner to take the necessary actions.

• Scenario 2: If the StageName is updated but does not change to "Negotiation/Review":

• No email is sent.

Email Notification: