Interview Questions on Batch Apex in Salesforce

 We use Batch Apex in Salesforce mainly to handle large volumes of data or long-running jobs that can’t be processed in a single transaction because of governor limits.

1. Process Large Data Sets

• A normal Apex transaction can only handle up to 50,000 records in SOQL and DML limits.
• Batch Apex lets you break the work into smaller chunks (called batches) of up to 2000 records per execution, so you can process millions of records without hitting limits.

2. Avoid Governor Limits

• Each batch execution runs in its own transaction.
• This means limits (like DML statements, SOQL queries, heap size) are reset for every batch.

Example: if you update 1 million Accounts, each batch of 200 records runs separately with fresh limits.

3. Asynchronous Processing

• Batch jobs run in the background, so they don’t block the user interface.
• Great for heavy operations like data cleansing, recalculations, archiving, or external system sync.

4. Callouts with Large Data

• Batch Apex supports callouts when you add Database.AllowsCallouts.
• Useful if you need to send large numbers of records to an external system without timing out.

5. Error Handling

• If one batch fails, the others still continue.
• You don’t lose the entire job because of a single bad record.

In short

We use batches when we need to process or update very large sets of records, avoid hitting limits, run asynchronously, or handle external integrations at scale.

Agree with this point if and only if the data needs to be updated is static or predefined or which can be done through excel.

We will choose batch class if we have to perform some custom calculations at run time or if you want to run some complex logic which can't be driven by excel sheets in those cases we have to go with batch classes.

For Examples:

• Do some relationship quires to update the data.
• Make a call out to get the some information related to each record.

It is Database.Batchable interface.

Example

global class MyBatchClass implements Database.Batchable<sobject>, Database.AllowsCallouts {
    global Database.QueryLocator start(Database.BatchableContext bc) {
        return Database.getQueryLocator('SELECT Id, Name FROM Account');
    }

    global void execute(Database.BatchableContext bc, List<account> scope) {
        // Your logic here (DML, callouts, etc.)
    }

    global void finish(Database.BatchableContext bc) {
        // Send email, log results, etc.
    }
}

So the main interface is Database.Batchable<T>, and you add Database.AllowsCallouts if external API calls are required.

Batch Jobs can be operated on any size of records, with a maximum of 200 records per batch. Each batch is a transaction. The Apex governor limits are reset for each transaction.

Yes — The Batch class executes every transaction, by breaking down large sets of data into small chunks and providing us with the additional benefit of a governor limit.

It provides us with a higher SOQL query limit. It implements a Database.Batchable interface.

Database.Batchable Interface has three methods that we have to implement:

1. Start – We collected the records either with a Database.QueryLocator or Iterable to pass them in the execute.
2. Execute – We performed the logic on the collected data. It will run multiple times according to the batch size.
3. Finish – We can do any post activities like sending emails.

global class batch implements Database.Batchable <sObject> { 
    global (Database.QueryLocator or  Iterable<sobject>)
        start(Database.BatchableContext bc) { 
            //query on object; 
            //return Database.getQueryLocator(query); 
        } 
    global void execute(Database.batchableContext bc, List <SObject> scope) { 
        //some processing. 
    } 
    global void finish(Database.BatchableContext bc) { 
        //job such as sending email or calling another batch class 
    } 
}

 Both Database.QueryLocator and Iterable<sObject> can be used in the start method of a Batch Apex class, but they behave differently.

1. Database.QueryLocator

• Used when you want to fetch records using SOQL.
• Returns up to 50 million records (huge scalability).
• Automatically handles record chunking for the batch framework.
• Best for straightforward queries where the data set can be retrieved with SOQL.

Example

global Database.QueryLocator start(Database.BatchableContext bc) {
    return Database.getQueryLocator('SELECT Id, Name FROM Account WHERE Active__c = true');
}

2. Iterable<sObject>

• Used when records are coming from a custom source, not just a SOQL query.
• You implement the Iterable and Iterator interfaces to control how records are returned.
• More flexible, because you can combine multiple queries, add complex logic, or even pull data from custom collections.
• But it’s limited to 50,000 records (normal governor limits apply).

Example

global Iterable<Account> start(Database.BatchableContext bc) {
    List<account> accList = [SELECT Id, Name FROM Account WHERE Active__c = true];
    return accList; // acts as an Iterable
}

Key Differences at a Glance

Simple rule of thumb

• If you just need records from one SOQL —> use QueryLocator.
• If you need custom data sets, logic, or non-SOQL sources —> use Iterable.

 Exactly - let's look at this, as Iterable in Batch Apex is often confusing.

What is Iterable in Batch Apex?

When you implement Database.Batchable, the start method must return either:

• a Database.QueryLocator (from SOQL), or
• an Iterable<T> (a collection you control).

The Iterable approach gives you custom scope — meaning you decide what records (or objects) the batch should process, and in what order, instead of Salesforce doing it for you through a simple SOQL query.

What do we mean by Custom Scope?

"Custom scope" means you can create your own list of records, objects, or even data not directly fetched from SOQL. Examples:

• Combine records from multiple queries.
• Filter data in memory after running some logic.
• Create artificial data (not even from Salesforce objects) for batch processing.
• Process records from a custom web service call.

Basically, you’re not tied to a single SOQL query — you define your own data set.

  Yes — that’s actually one of the main advantages of using Iterable<sObject> instead of Database.QueryLocator.

Why?

• With Database.QueryLocator, Salesforce controls the order. You can add ORDER BY in SOQL, but once the records are chunked into batches, you don’t have fine-grained control.
• With Iterable, you create and pass your own list/collection. That means you decide the exact order of elements in that list. The batch framework will respect that order while chunking into scope lists.

Example

Suppose you want to process Accounts ordered by Annual Revenue descending (highest-paying customers first):

global class RevenueBatch implements Database.Batchable<sObject> {

    global Iterable<sObject> start(Database.BatchableContext bc) {
        // Get accounts ordered by revenue
        List<Account> accList = [
            SELECT Id, Name, AnnualRevenue 
            FROM Account 
            WHERE Active__c = true
            ORDER BY AnnualRevenue DESC
        ];
        return accList; // preserves order
    }

    global void execute(Database.BatchableContext bc, List<sObject> scope) {
        for (Account acc : (List<Account>)scope) {
            System.debug('Processing: ' + acc.Name + ' Revenue: ' + acc.AnnualRevenue);
        }
    }

    global void finish(Database.BatchableContext bc) {
        System.debug('Batch finished.');
    }
}

Here, each chunk of 200 records (default batch size) will be processed in the same order you defined in your list.

 Not always. It depends on which start method you use.

If you use Database.QueryLocator

• You can add ORDER BY in the SOQL.
• Example:

global Database.QueryLocator start(Database.BatchableContext bc) {
    return Database.getQueryLocator(
        'SELECT Id, Name FROM Account ORDER BY AnnualRevenue DESC'
    );
}

If you use Iterable<sObject>

• You construct your own collection (list, custom iterable).
• The order you define in the list is preserved within the batch scopes.
• However, same limitation: if Salesforce decides to run scopes in parallel, you can’t control which batch of 200 executes first.

So the correct answer is

You can process data in a specific order within each batch scope, but you cannot strictly enforce a sequential order across all scopes.

 Yes, you can query related records with Database.QueryLocator, because it supports all standard SOQL relationship queries (both parent-to-child and child-to-parent). The only limitation is that the batch scope is based on the main object in your query.

 No. You cannot use FOR UPDATE with Database.QueryLocator.

Why?

• Database.QueryLocator is designed for large-volume, read-only streaming of records (up to 50 million).
• Adding FOR UPDATE would try to lock all those rows in a single transaction, which isn’t supported.
• Salesforce docs explicitly say:

"FOR UPDATE is not allowed with Database.getQueryLocator()."

What if you need row locking in Batch Apex?

1. Use the Iterable<sObject> start method instead of QueryLocator.

• Query your records with FOR UPDATE using standard SOQL.
• Put them in a List and return it as an Iterable.

global class LockingBatch implements Database.Batchable<sObject> {
    global Iterable<sObject> start(Database.BatchableContext bc) {
        List<Account> accs = [
            SELECT Id, Name FROM Account WHERE Active__c = true FOR UPDATE
        ];
        return accs;
    }

    global void execute(Database.BatchableContext bc, List<sObject> scope) {
        // Process with records locked
    }

    global void finish(Database.BatchableContext bc) {}
}

• Alternatively, you can use SELECT ... FOR UPDATE in smaller, on-demand queries inside execute().

That way you only lock the records being processed in the current scope.

 Batch Apex is typically stateless. Each execution of a batch Apex job is considered a discrete transaction.
For example, a batch Apex job that contains 1,000 records and uses the default batch size is considered five transactions of 200 records each.

 The Processing order can’t be controlled, but we can bypass the Record B processing before Record A. We can implement Database.STATEFUL and use one class variable to track whether Record A has processed or not. If not processed and Record B has come, don’t process Record B. After all the execution completes, Record A has already been processed so Run the batch again, to process Record B.

 Database.Stateful is a Marker interface helps in maintaining state across transactions. When using Database.Stateful, only instance member variables retain their values between transactions.
Static member variables don’t retain their values and are reset between transactions.

Maintaining state is useful for counting or summarizing records as they’re processed.
For example, we’ll be updating contact records in our batch job and want to keep track of the total records affected so we can include it in the notification email.

Database.Stateful : Used to keep track of data in every batch execution. (If a execute/finish method required data from previous execute method)

 Database.AllowsCallouts is another Marker Interface, which is implemented to make HTTP callouts through Batch.

 To monitor the status of the jobs
 1. From Setup, enter Jobs in Quick Find box
 2. Select Apex Jobs

–> Go to Setup --->Apex Job page

We can monitor progress going to -> Setup -> Apex Jobs (will get job id)

To get details using Job ID : (Perform query on AsyncApexJob object)
AsyncApexJob jobInfo = [SELECT Status,NumberOfErrors FROM AsyncApexJob WHERE Id=:jobID];

 If the start method of the batch class returns a QueryLocator, the optional scope parameter of Database.executeBatch can have a maximum value of 2,000. If set to a higher value, Salesforce chunks the records returned by the QueryLocator into smaller batches of up to 2,000 records. If the start method of the batch class returns an iterable, the scope parameter value has no upper limit.

 If any record fails all 200 record will fail but next batch will get executed.

 Basically in salesforce we have limitation of 100 call outs for a transaction. When it comes to batch class each execute method call will be considered as one transaction. So, in this case your batch size must be calculated in such way

Batch size = (No of callouts allowed for single transaction /total number of call outs for each record) - 1;

Batch size = (100 /total number of call outs for each record) - 1;

 It depends on your batch size what you have configured at the time of calling the batch class from schedule class.

Execution method count = Total No Of Records/Batch Size (Any decimal ceil it to upper value)

If you haven't set any batch size then :

	1236	= 6.18	= 7 times execute method will be called
	200

 Yes, we can call from the finish method.

 Only in batch class finish method, We can call another batch class. If you will call another batch class from batch class execute and start method, then Salesforce will throw below runtime error.

System.AsyncException: Database.executeBatch cannot be called from a batch start, batch execute, or future method.

 Because the execute method will gets invoked multiple times based on the volume of the records and batch size. So, if your calling it from execute method then the chaining class will get called multiple times which is not an suggested way of doing.

We can also use the Queueable Apex for chaining of the jobs.

 In batches, If the first transaction succeeds but the second fails, the database updates made in the first transaction are not rolled back.

Since the batch size is 200, so the first batch will be processed completely and all data will be committed to DB. In seconds batch, if we are committing records using normal DML statements like insert, update than the whole batch will be rollbacked. So records 201 to 400 will not be processed.

If we use the Database DML operations like Database.insert with AllOrNone as false, then partial commit can happen and only 398th record will not be processed in that batch and total 199 records will be processed. Also, the other batch execution will not gonna be hampered.

 Methods declared as future can’t be called from a batch Apex class.

  As we know that a webservice can be called from batch class and webservice can call @future method. So in your batch class call web service and which can call your @future method. Also, you can call future methods from the finish method in the batch class.

  At most, there can be 5 batch jobs queued at a time.

 Yes, it is possible. We can call a batch apex from trigger but we should always keep in mind that we should not call batch apex from trigger each time as this will exceeds the governor limit this is because of the reason that we can only have 5 apex jobs queued or executing at a time.

 To make a Webservice callout in batch Apex, we have to implement Database.AllowsCallouts interface.

 Start method, finish method one time, execute method it depends on requirement. Based on the batch size and data retrieved in Start method.

 The maximum number of batch executions is 250,000 per 24 hours.

  The job Id returned by the batchable context variable helps us in finding the status of a batch through AsyncApexJob object. For example,

global void finish(Database.BatchableContext info){ 

    // Get the ID of the AsyncApexJob representing this batch job
    // from Database.BatchableContext.
    // Query the AsyncApexJob object to retrieve the current job's information.

    AsyncApexJob a = [SELECT Id, Status, NumberOfErrors, JobItemsProcessed,
                      TotalJobItems, CreatedBy.Email FROM AsyncApexJob WHERE Id = :info.getJobId()];
    
    // Send an email to the Apex job's submitter notifying of job completion.

    Messaging.SingleEmailMessage mail = new Messaging.SingleEmailMessage();
    
    String[] toAddresses = new String[] {a.CreatedBy.Email};
    mail.setToAddresses(toAddresses);
    mail.setSubject('Account and contact update' + a.Status);
    mail.setPlainTextBody
        
        ('The batch Apex job processed ' + a.TotalJobItems +
         ' batches with '+ a.NumberOfErrors + ' failures.'+successRecord+'successRecordids: '+ 'failRecordids: '+ failRecord);
    Messaging.sendEmail(new Messaging.SingleEmailMessage[] { mail });
}

 The Database.executeBatch and System.scheduleBatch method returns an ID that can be used in System.abortJob method.

global class CaseCreationonSchedular implements Schedulable
{
    global void execute(SchedulableContext SC)
    {
        
        for(AsyncApexJob ap: [SELECT Id, ApexClass.Name,createddate, JobType, Status, JobItemsProcessed, MethodName, ParentJobId 
                                     FROM AsyncApexJob 
                                     Where ParentJobId!=Null 
                                     AND JobType IN('BatchApex','BatchApexWorker') 
                                     And ApexClass.Name='YourBatchClassName' 
                                     And Status NOT IN('Completed','Aborted')])
        {
            System.abortJob(ap.ParentJobId);
            
        }
        YourBatchClassName cls = new YourBatchClassName();
        DataBase.executeBatch(cls);
    }
}

 At a time salesforce allows 5 batches to be running or to be in queued state. So, if you have consumed all these 5 limits and if system has received one or more batch execution request all these waiting batch will be stored in this Apex Flex Queue.

The maximum number of batch classes allowed in Apex Flex Queue for execution is 100.

 Once you run Database.executeBatch, the Batch jobs will be placed in the Apex flex queue and its status becomes Holding. The Apex flex queue has the maximum number of 100 jobs, Database.executeBatch throws a LimitException and doesn’t add the job to the queue. So atmost 100 jobs can be added in one go.

Also, if Apex flex queue is not enabled, the Job status becomes Queued, Since the concurrent limit of the queued or active batch is 5, so atmost 5 batch jobs can be added in one go.

 Only jobs having status as Holding can be moved. It can be done through UI of Apex Flex queue or we can use Apex Flex Queue Methods.

Boolean isSuccess = System.FlexQueue.moveBeforeJob(jobToMoveId, jobInQueueId);

 Through System.scheduleBatch Method, we can schedule batch for once at a future time. This method returns the scheduled job ID also called CronTrigger ID.

String cronID = System.scheduleBatch(reassign, 'job example', 1);

CronTrigger ct = [SELECT Id, TimesTriggered, NextFireTime
                  FROM CronTrigger WHERE Id = :cronID];

 No — you cannot make synchronous web service callouts directly from a scheduled Apex class. Salesforce enforces this limitation because scheduled jobs run in a system context where synchronous callouts are not allowed.

What Happens If You Try?

If you write code in a Schedulable class that performs a synchronous callout (e.g., using HttpRequest and HttpResponse without a continuation), you will receive a fatal, un-catchable exception at runtime:

System.AsyncException: Synchronous operation not allowed from async context: Schedule

Your scheduled job will fail, and you will see this error in the Apex Jobs log (Setup -> Monitoring -> Apex Jobs).

 Yes..!! We can call the scheduler from the future method.

 No, If there are one or more active scheduled jobs for an Apex class, you cannot update the class or any classes referenced by this class through the Salesforce user interface.

 Yes, But you’re limited to just one System.enqueueJob call per execute in the Database.Batchable class. Salesforce has imposed this limitation to prevent explosive execution.

 We can test it by calling the Batch job between Test.startTest() and Test.stopTest(). Using the Test methods startTest and stopTest around the executeBatch method to ensure that it finishes before continuing your test. All asynchronous calls made after the startTest method are collected by the system. When stopTest is executed, all asynchronous processes are run synchronously.

Also we can test only one execution of the execute method. So we need to set the scope as per the governor limits.

 We have to make sure that the number of records inserted is less than or equal to the batch size of 200 because test methods can execute only one batch. We must also ensure that the Iterable returned by the start method matches the batch size.