Salesforce Apex Interview Questions and Answers

 To avoid SOQL in loops:

1. Use maps to store query results and retrieve them in constant time.
2. Use collections to fetch related records in a single query before processing.
3. Leverage relationship queries (e.g., parent-child or child-parent queries) where possible.

For Example:
I would use maps to hold query results and prevent repeated queries in a loop. For instance, in an Opportunity trigger, I would query related Account records in bulk at the start and store them in a map keyed by AccountId for efficient lookup.

 I would use Batch Apex for large data volumes (up to 50 million records) requiring chunk-based processing. Queueable Apex is better for lightweight jobs requiring chaining or complex data structures.

For Example:
If I need to process over 50,000 records with retry logic, I would choose Batch Apex due to its scalability. For simpler tasks, like updating related records in a single transaction, Queueable Apex would be more appropriate.

 Before triggers are used for updating or validating data before it is saved to the database, as the records are still in memory.

After triggers are used when data needs to be committed to the database, such as creating related records or performing actions dependent on saved data.

For Example:
I would use a before trigger for updating a record’s field value, such as setting a default status. For example, Trigger.new allows in-memory updates without an explicit DML statement. For tasks like inserting child records based on a saved parent, I would choose an after trigger.

 To handle DML limit issues:

1. Use collections to group records and perform bulk DML operations.
2. Consolidate triggers using a trigger handler framework.
3. Use asynchronous processing for heavy DML operations.

For Example:
I would review the code to ensure all DML operations are grouped into a single operation. For instance, instead of updating records individually, I would add them to a list and perform a bulk update at the end of the transaction.

 To handle a scenario where a Batch Apex class processes millions of records and fails mid-execution, I would design the batch to ensure it can restart from the failure point by leveraging stateful batch processing and proper error handling mechanisms. Here’s my approach:

1. Use of Database.Stateful:

• By implementing the Database.Stateful interface, I can maintain state across batch chunks. This allows me to track successfully processed records and resume from where the failure occurred.

• Error Handling:

• I would implement try-catch blocks within the execute method to handle individual record errors without failing the entire batch.
• Any failed records would be logged in a custom object or a collection for retry processing.

• Tracking Progress:

• Maintain a collection (e.g., a Set<Id> or List<Id>) to store successfully processed record IDs.
• In the event of a failure, these IDs help determine where the process left off.

• Restarting the Batch:

• If the batch fails entirely (e.g., due to governor limits or system exceptions), the admin or system can restart it manually.
• The start method can filter out already processed records using the stored IDs.

• Code Example Outline:

public class MyBatchClass implements Database.Batchable<SObject>, Database.Stateful {
    private Set<Id> processedRecordIds = new Set<Id>();

    // Start method
    public Database.QueryLocator start(Database.BatchableContext bc) {
        // Query records not already processed
        return Database.getQueryLocator([
            SELECT Id, Name FROM MyObject__c WHERE Id NOT IN :processedRecordIds
        ]);
    }

    // Execute method
    public void execute(Database.BatchableContext bc, List<SObject> scope) {
        try {
            for (SObject record : scope) {
                // Process record
                MyObject__c obj = (MyObject__c) record;
                // Simulate processing logic
                obj.Status__c = 'Processed';
                update obj;

                // Mark record as processed
                processedRecordIds.add(obj.Id);
            }
        } catch (Exception ex) {
            // Log error
            System.debug('Error processing batch: ' + ex.getMessage());
        }
    }

    // Finish method
    public void finish(Database.BatchableContext bc) {
        // Notify admin of completion or failure details
        Messaging.SingleEmailMessage email = new Messaging.SingleEmailMessage();
        email.setSubject('Batch Process Complete');
        email.setPlainTextBody('The batch process completed successfully.');
        email.setToAddresses(new String[] {'admin@example.com'});
        Messaging.sendEmail(new Messaging.SingleEmailMessage[] {email});
    }
}

• Retry Mechanism for Failed Records:

• For records that fail in the execute method, I would store their IDs in a custom object or a static resource.
• A subsequent batch job or manual trigger can reprocess these records.

• Governor Limit Considerations:

• By processing records in smaller chunks and using optimized SOQL queries, I would minimize the risk of hitting limits.
• I would also ensure bulk-safe operations (e.g., using collections for DML statements).

This design ensures the batch can restart from the failure point using Database.Stateful, tracks processed records, handles individual errors gracefully, and retries failed records in subsequent executions. It aligns with Salesforce best practices for scalability and resilience.

Ideal Answer

To ensure the batch restarts from the failure point, I would implement the Database.Stateful interface to maintain state between batch executions. By maintaining a record of successfully processed IDs in an instance variable, I can exclude them in subsequent queries. Additionally, I would include a try-catch block in the execute() method to log errors and track where the failure occurred. Using tools like the Database.saveResult object allows me to capture partial success in bulk DML operations.

Example Response from Interviewee

Batch Apex with millions of records demands both efficiency and error resilience. Implementing Database.Stateful ensures that variables like processed IDs persist across transactions. If a failure occurs, I use error logging to identify failed records, ensuring I can restart the batch without duplicating work. Governor limits would also guide how I design the logic, especially to avoid memory limits.

 Queueable Apex allows chaining by calling System.enqueueJob() within the execute() method. To pass complex objects like maps or lists, these must be serializable. If a candidate passes an unserializable object, such as a transient variable, it leads to runtime issues. Additionally, Salesforce limits chaining to 50 jobs per transaction, which must be respected to avoid job rejection.

For Example: I would ensure that any data passed between chained Queueable jobs is serializable, such as using lists or JSON strings for more complex structures. If chaining more than 50 jobs is required, I would redesign the process to group records in batches. Proper exception handling is also necessary to ensure no data loss during chaining.

 Mixed DML errors occur when DML operations on setup and non-setup objects are performed in the same transaction. Future methods allow these operations to run in separate transactions. However, as Future methods do not guarantee execution order, alternative solutions like Queueable Apex are preferred in scenarios requiring dependency.

For Example: I would structure a Future method to handle DML operations on User records separately from custom object DMLs, thus preventing mixed DML issues. Since Future methods don’t guarantee order, if dependency exists, I would opt for Queueable Apex or Platform Events to orchestrate the sequence.

When to Use a Future Method

• If a transaction requires updates to both a User record and a Custom Object record, the updates to the User record must occur in a separate asynchronous transaction.
• For example, if creating a record for a custom object requires updating a related User record, the User update must be done using a Future method.

How to Structure It

1. Create a Future Method:

• Use the @future annotation to make the method asynchronous.
• Pass only primitive data types (e.g., Id, String) as parameters to the method.

• Design the Transaction Flow:

• Perform synchronous DML operations on the Custom Object in the main transaction.
• Invoke the Future method to update the User record asynchronously.

Code Example

public class UserUpdateService {

    // Future method for asynchronous User updates
    @future
    public static void updateUserDetails(Set<Id> userIds) {
        try {
            // Fetch and update User records
            List<User> usersToUpdate = [SELECT Id, IsActive FROM User WHERE Id IN :userIds];
            for (User usr : usersToUpdate) {
                usr.IsActive = false; // Example update
            }
            update usersToUpdate;
        } catch (Exception e) {
            System.debug('Error updating User records: ' + e.getMessage());
        }
    }

    // Main method to handle Custom Object and User updates
    public static void processRecords(Id customObjectId, Id userId) {
        // Custom Object DML
        CustomObject__c customObj = [SELECT Id, Name FROM CustomObject__c WHERE Id = :customObjectId];
        customObj.Status__c = 'Processed';
        update customObj;

        // Asynchronous User Update
        Set<Id> userIds = new Set<Id>{userId};
        updateUserDetails(userIds);
    }
}

Explanation

1. The processRecords method handles the synchronous operation (Custom Object update) and invokes the Future method for the asynchronous User update.
2. The @future method (updateUserDetails) ensures that User record updates occur in a separate transaction.

A Future method is essential for handling operations on both User and Custom Object records within the same logical process due to Salesforce's DML restrictions. Structuring the transaction as shown ensures compliance with these restrictions while maintaining functionality.

 To prevent duplicate Contact records based on the Email field during insertion, we need to consider both single-record and bulk operations. The solution should be efficient, bulk-safe, and compliant with Salesforce governor limits.

Here’s how I would implement this:

Apex Trigger
The trigger will invoke a helper class to handle the duplicate check.

trigger ContactTrigger on Contact (before insert) {
    if (Trigger.isBefore && Trigger.isInsert) {
        ContactDuplicateHandler.preventDuplicateContacts(Trigger.new);
    }
}

Apex Class for Duplicate Prevention

public class ContactDuplicateHandler {
    public static void preventDuplicateContacts(List<Contact> newContacts) {
        // Step 1: Collect all Emails from the incoming records
        Set<String> emailSet = new Set<String>();
        for (Contact con : newContacts) {
            if (con.Email != null) {
                emailSet.add(con.Email.toLowerCase()); // Normalize to handle case sensitivity
            }
        }

        // Step 2: Query existing Contacts with matching Emails
        Map<String, Id> existingContacts = new Map<String, Id>();
        if (!emailSet.isEmpty()) {
            for (Contact existingCon : [
                SELECT Id, Email FROM Contact WHERE Email IN :emailSet
            ]) {
                existingContacts.put(existingCon.Email.toLowerCase(), existingCon.Id);
            }
        }

        // Step 3: Check for duplicates and add errors
        for (Contact con : newContacts) {
            if (con.Email != null && existingContacts.containsKey(con.Email.toLowerCase())) {
                con.addError('Duplicate Contact detected. A Contact with this Email already exists.');
            }
        }
    }
}

Explanation

1. Email Normalization:

• Convert emails to lowercase to ensure case-insensitive comparison.

• Bulk-Safe Design:

• Use a single SOQL query to fetch all existing contacts with matching emails.
• Avoid governor limit violations by working with collections (Set, Map).

• Error Handling:

• Use the addError() method to block duplicate records and display an appropriate message to the user.

• Trigger Context:

• The solution is designed for the before insert context to avoid unnecessary DML operations.

Bulk Operation Example

Suppose a user tries to insert the following contacts:

1. John Doe - Email: john.doe@example.com
2. Jane Doe - Email: jane.doe@example.com
3. Duplicate John - Email: john.doe@example.com

The class will detect that Duplicate John conflicts with an existing record and prevent its insertion while allowing the others.

This design ensures the prevention of duplicate Contact records in a scalable and bulk-safe manner, adhering to Salesforce best practices.

 To fetch and return all Contact records associated with Accounts in a specific Industry, the solution must handle dynamic querying and ensure it is bulk-safe and governor-limit compliant.

Here’s how I would design the class:

Apex Class

public class ContactFetcherByIndustry {
    /**
     * Fetches and returns all Contact records associated with Accounts in a specific Industry.
     * @param industryName The name of the Industry to filter Accounts by.
     * @return List<Contact> A list of Contacts associated with the specified Industry's Accounts.
     */
    public static List<Contact> fetchContactsByIndustry(String industryName) {
        if (String.isBlank(industryName)) {
            throw new IllegalArgumentException('Industry name cannot be null or empty.');
        }

        // Query to fetch Contacts dynamically
        List<Contact> contacts = [
            SELECT Id, FirstName, LastName, Email, Account.Name, Account.Industry
            FROM Contact
            WHERE Account.Industry = :industryName
        ];

        return contacts;
    }
}

Explanation

1. Dynamic Query:

• The SOQL query dynamically filters Contact records based on the Industry field of the related Account.

• Null or Blank Check:

• Validates the industryName parameter to ensure it is not null or empty.

• Field Selection:

• The query fetches Contact fields (FirstName, LastName, Email) and relevant Account fields (Name, Industry) for better visibility and debugging.

• Method Return Type:

• The method returns a List<Contact> containing all matching records.

• Governor Limits:

• The class handles bulk-safe design by adhering to the SOQL limit (50,000 rows). If the result set exceeds this limit, a Batch Apex solution would be required.

Usage Example

To use this class in an Apex method or Lightning component:

List<Contact> healthcareContacts = ContactFetcherByIndustry.fetchContactsByIndustry('Healthcare');
System.debug('Fetched Contacts: ' + healthcareContacts);

This retrieves all Contacts associated with Accounts in the Healthcare industry.

This class is simple, efficient, and scalable, providing a dynamic solution to fetch Contacts based on Account industries while ensuring compliance with Salesforce best practices.

Steps

1. Open Salesforce Developer Console.
2. Go to Debug > Open Execute Anonymous Window.
3. Paste the following code and click Execute:

// Fetch contacts for a specific industry
List<Contact> contacts = ContactFetcherByIndustry.fetchContactsByIndustry('Healthcare');

// Output the result to the debug log
System.debug('Fetched Contacts: ' + contacts);

Check Output

• Open the Logs tab in the Developer Console.
• Look for the log entry and inspect the Fetched Contacts debug statement to see the list of contacts.

 To log exceptions into a custom object named Error_Log__c, we can create a utility class that captures error details and inserts them into the custom object. The fields to be logged include:

• Error_Message__c: The error message.
• Class_Name__c: The name of the class where the error occurred.
• Method_Name__c: The name of the method where the error occurred.

Apex Utility Class

public class ErrorLogger {
    /**
     * Logs an exception to the Error_Log__c custom object.
     *
     * @param exception The exception to log.
     * @param className The name of the class where the error occurred.
     * @param methodName The name of the method where the error occurred.
     */
    public static void logError(Exception exception, String className, String methodName) {
        try {
            // Create an instance of the custom error log object
            Error_Log__c errorLog = new Error_Log__c();
            errorLog.Error_Message__c = exception.getMessage();
            errorLog.Class_Name__c = className;
            errorLog.Method_Name__c = methodName;

            // Insert the error log record
            insert errorLog;
        } catch (Exception loggingException) {
            // Prevent logging failure from affecting the main process
            System.debug('Error while logging exception: ' + loggingException.getMessage());
        }
    }
}

How to Use the Utility Class
In any Apex class or trigger, you can use this utility class to log exceptions. Here's an example:

public class SampleClass {
    public static void performOperation() {
        try {
            // Simulated code that may throw an exception
            Integer result = 5 / 0;  // This will cause a division by zero exception
        } catch (Exception e) {
            // Log the exception using the ErrorLogger utility
            ErrorLogger.logError(e, 'SampleClass', 'performOperation');
        }
    }
}

Explanation

1. Method Parameters:

• exception: The caught exception to log.
• className and methodName: Passed explicitly to identify where the error occurred.

• Creating the Error Log:

• An Error_Log__c object is created and its fields are populated with the error details.

• Insert Operation:

• The errorLog object is inserted into the Error_Log__c custom object.

• Error Handling During Logging:

• The try-catch inside the logging process ensures that even if logging fails, it won’t affect the main process.

Output

An Error_Log__c record is created with details of the exception, including the error message, class name, and method name.

 To update all Lead records with the status "Open - Not Contacted" to "Working", we need to create two Apex classes:

1. Batch Apex Class: This class will update all Lead records where the Status is "Open - Not Contacted", changing it to "Working".
2. Scheduled Apex Class: This class will schedule the batch class to run daily at midnight.

1. Batch Apex Class

public class UpdateLeadStatusBatch implements Database.Batchable<sObject> {

    // Query to fetch Lead records with Status 'Open - Not Contacted'
    public Database.QueryLocator start(Database.BatchableContext context) {
        return Database.getQueryLocator([SELECT Id, Status FROM Lead WHERE Status = 'Open - Not Contacted']);
    }

    // Process each batch of records
    public void execute(Database.BatchableContext context, List<Lead> leadList) {
        for (Lead lead : leadList) {
            lead.Status = 'Working';  // Update Status
        }
        update leadList;  // Perform bulk update
    }

    // Called once after all batches are processed
    public void finish(Database.BatchableContext context) {
        System.debug('Batch job to update Lead statuses completed.');
    }
}

2. Scheduled Apex Class
This class schedules the UpdateLeadStatusBatch to run daily at midnight.

public class UpdateLeadStatusScheduler implements Schedulable {
    public void execute(SchedulableContext context) {
        // Run the batch job with 200 records per batch
        UpdateLeadStatusBatch batchJob = new UpdateLeadStatusBatch();
        Database.executeBatch(batchJob, 200);
    }
}

3. Schedule the Job
To schedule the job to run daily at midnight, use the Developer Console or Anonymous Apex Execution:

// Schedule to run daily at midnight (0 AM)
String cronExp = '0 0 0 * * ?';  // Cron expression for midnight
UpdateLeadStatusScheduler schedulerJob = new UpdateLeadStatusScheduler();
System.schedule('Daily Lead Status Update', cronExp, schedulerJob);

Explanation

1. Batch Class Workflow:

• Start Method: Queries all Lead records with Status = "Open - Not Contacted".
• Execute Method: Updates the Status field to "Working".
• Finish Method: Logs a message upon completion (optional for additional processing).

• Scheduler Class:

• Implements the Schedulable interface to run the batch job.
• Calls the batch class using Database.executeBatch() with a batch size of 200.

• Cron Expression:

• '0 0 0 * * ?' schedules the job at midnight.
• You can customize this for different times if needed.

Expected Output:
When the batch job and scheduled class run successfully, the following outcomes can be observed:

1. Lead Record Updates:

• All Lead records with Status = "Open - Not Contacted" will have their Status updated to "Working" daily at midnight.
• The Last Modified Date and Last Modified By fields on the updated Lead records will reflect the batch update.

• System Logs:

• After processing, a debug message will appear in the Developer Console:

Batch job to update Lead statuses completed.