Salesforce Apex Asynchronous Processing Explained: When to Use Batch, Queueable, and Scheduled
If you have spent meaningful time building on the Salesforce platform, you already know the golden rule: never make the user wait. Whether it is processing thousands of records, sending outbound callouts, or running complex calculations, doing that work synchronously is a recipe for hitting governor limits and degrading user experience.
That is where Apex asynchronous processing comes in. Salesforce offers four distinct async mechanisms: @future methods, Queueable Apex, Batch Apex, and Scheduled Apex. Each solves a different problem, each has its own governor limit profile, and each has situations where it shines and situations where it will cause you pain if misused.
This guide cuts through the confusion and gives you a clear, developer-focused breakdown of all four, including when to use each, how they interact with governor limits, chaining patterns, and real-world scenarios drawn from production Salesforce environments.
Why Asynchronous Processing Matters in Salesforce?
Synchronous Apex runs in real time, shares a transaction boundary with everything else happening in that context, and is tightly bound to Salesforce governor limits. When a user clicks a button that triggers complex logic, say, recalculating opportunity scores across 10,000 records that cannot and should not happen synchronously.
Asynchronous execution defers work to a background queue, grants a separate (and in most cases more generous) governor limit allocation, and allows the platform to manage execution scheduling. This is not just a performance concern it is an architectural necessity in enterprise Salesforce implementations.
The challenge is knowing which tool to reach for. Here is how to make that decision confidently.
The Four Salesforce Asynchronous Processing Tools: A Quick Orientation
@future Methods — Fire and Forget
The @future annotation is the oldest and simplest async mechanism in Apex. It runs a static method in a future context meaning it executes after the current transaction completes.
Key features include:
- Accepting only primitive data types or a collection of primitives as arguments; no sObjects
- Being called from outside another @future or Batch method context
- Lacking any method of tracking progress or monitoring from code
- HTTP callout ability, when callout = true
Example use case:
public class LeadScoringHelper {
@future(callout=true)
public static void sendLeadToExternalSystem(Id leadId, String status) {
// Perform HTTP callout without blocking the transaction
HttpRequest req = new HttpRequest();
req.setEndpoint(‘callout:Lead_Scoring_API/leads’);
req.setMethod(‘POST’);
req.setBody(JSON.serialize(new Map<String,Object>{
‘leadId’ => leadId,
‘status’ => status
}));
new Http().send(req);
}
}
When to use @future: Use it for simple, one-off fire-and-forget operations — particularly outbound HTTP callouts that must happen after the main transaction commits. Avoid it when you need to pass complex data, chain multiple operations, or track execution status.
Queueable Apex — The Intelligent Successor
Queueable Apex was introduced to address the significant limitations of @future methods. It implements the Queueable interface and is enqueued using System.enqueueJob(). It runs as a proper job with a trackable ID.
Key characteristics:
- Accepts any data type as member variables including sObjects and complex custom classes
- Returns a job ID that can be monitored via AsyncApexJob
- Supports chaining: one Queueable can enqueue another from its execute() method
- Can be called from triggers, batch finish() methods, and other async contexts
Example use case:
public class ContractRenewalQueueable implements Queueable {
private List<Contract> contracts;
public ContractRenewalQueueable(List<Contract> contracts) {
this.contracts = contracts;
}
public void execute(QueueableContext context) {
for (Contract c : contracts) {
c.Status = ‘Activated’;
c.StartDate = Date.today();
}
update contracts;
// Chain to next job if needed
if (!contracts.isEmpty()) {
System.enqueueJob(new NotificationQueueable(contracts));
}
}
}
Use of Queueable: Choose this method if there is a need to transfer complex objects, sequence asynchronous activities, or monitor the job execution. This is the most widely used asynchronous programming model in modern-day Salesforce development apart from the mass data operation use case.
Batch Apex – Made for Scale
Batch Apex is designed for high-volume data processing. It divides the volume into smaller scopes, which are processed in separate transactions, and provides lifecycle methods start(), execute(), and finish().
Properties:
- Supports processing of up to 50 million records with the help of Database.QueryLocator or Iterable
- One execute() call will process one scope (default 200, customizable from 1 to 2000)
- Separate transaction limits per batch scope
- 200 SOQL queries per batch
- Five simultaneous active batch jobs per organization (actual limitation to work with)
- Finish() is called after all batch iterations finish
Example use case:
public class AccountRiskScoringBatch implements
Database.Batchable<sObject>, Database.Stateful {
private Integer totalProcessed = 0;
public Database.QueryLocator start(Database.BatchableContext bc) {
return Database.getQueryLocator(
‘SELECT Id, AnnualRevenue, NumberOfEmployees FROM Account WHERE IsActive__c = true’
);
}
public void execute(Database.BatchableContext bc, List<Account> scope) {
for (Account acc : scope) {
acc.Risk_Score__c = calculateRisk(acc);
}
update scope;
totalProcessed += scope.size();
}
public void finish(Database.BatchableContext bc) {
System.debug(‘Total processed: ‘ + totalProcessed);
// Chain next batch or send notification
Database.executeBatch(new RiskNotificationBatch(), 200);
}
private Decimal calculateRisk(Account a) {
return (a.AnnualRevenue != null && a.AnnualRevenue < 100000) ? 8.5 : 3.0;
}
}
Batch Apex usage: You can consider using Batch Apex if you are required to process a very large number of records like migrating your data or doing some calculations overnight or bulk updates post some changes to schema or scheduled data enrichment. Avoid using batch in case of smaller record processing.
Scheduled Apex – Time Triggered Execution
Scheduled Apex enables the execution of Apex code based on a set schedule using cron syntax. Implements Schedulable interface and registers itself by calling System.schedule().
Characteristics include:
- Executes according to a schedule specified with a cron string down to minutes granularity
- Cannot perform mass record operations but can invoke Batch or Queueable process
- Up to 100 scheduled jobs per organization
- Can be seen in Setup | Scheduled Jobs; managed via CronTrigger object
Example use case:
public class NightlyDataCleanupScheduler implements Schedulable {
public void execute(SchedulableContext sc) {
// Launch batch from scheduled context
Database.executeBatch(new StaleLeadCleanupBatch(), 200);
}
}
// Schedule it from Developer Console or setup code:
// ‘0 0 2 * * ?’ = Every day at 2:00 AM
System.schedule(‘Nightly Lead Cleanup’, ‘0 0 2 * * ?’,
new NightlyDataCleanupScheduler());
When to use Scheduled Apex: Use it for time-driven automation nightly batch runs, weekly report generation, monthly data archiving. Think of Scheduled Apex as the trigger, not the workhorse. It should delegate heavy processing to Batch or Queueable rather than doing it directly.
Side-by-Side Comparison
Here is a quick reference to help you choose the right tool at a glance.
| Feature | @future | Queueable | Batch Apex | Scheduled Apex |
| Return type | void only | void / ID | void (execute) | void (execute) |
| Chaining | Not supported | Yes (1 level deep) | Yes (from finish()) | Yes (scheduleBatch) |
| SOQL limit | 100 queries | 100 queries | 200 queries | 100 queries |
| DML limit | 150 statements | 150 statements | 150 per batch | 150 statements |
| Custom objects allowed | No (only primitives) | Yes (any type) | Yes | Yes |
| Monitoring via UI | No | Yes (AsyncApexJob) | Yes (ApexJobId) | Yes (Scheduled Jobs) |
| Max concurrent jobs | 50 per org | Flexible | 5 active batches | 100 scheduled jobs |
| Best for | Fire-and-forget callouts | Complex chained logic | Mass record processing | Time-based automation |
Chaining Patterns: Building Multi-Step Async Pipelines
One of the most powerful and misunderstood aspects of Salesforce Asynchronous Processing is chaining. Here is how each tool handles it:
Queueable Chaining
From within a Queueable execute() method, you can enqueue the next job using System.enqueueJob(). However, in production you can only enqueue one child job per execution, not multiple. This is often used to build sequential processing pipelines where each step passes results to the next.
Batch Chaining
The finish() method in a Batch class is the natural handoff point. Call Database.executeBatch() inside finish() to trigger the next batch or any other async job. This is how you build ETL pipelines or multi-stage data processing workflows.
Scheduled to Batch
The most common pattern in enterprise Salesforce orgs is a Scheduled Apex job that fires nightly and launches one or more Batch jobs. This keeps scheduling logic clean and separates timing concerns from processing logic.
What to Avoid
- Calling @future from a Batch context as this will throw an exception
- Chaining more than one Queueable per execute() in production
- Running Scheduled Apex that directly does heavy DML or SOQL instead of delegating to Batch
Governor Limit Considerations by Async Type
Each async context has its own governor limit allocation. Understanding this is critical when choosing between options:
- @future and Queueable share the standard async limit pool (100 SOQL, 150 DML). They do not get the generous limits that Batch does.
- Batch Apex per-scope execution gets 200 SOQL queries useful when each chunk of records needs significant query work.
- Database.Stateful in Batch allows you to carry instance variables across batches, but increases memory pressure. Use sparingly.
- The heap size limit in async is 12MB up from 6MB in synchronous which matters when deserializing large payloads in Queueable or @future.
- Callouts are allowed in @future (callout=true), Queueable, and Batch (with Database.AllowsCallouts) but NOT by default in Scheduled Apex.
Real-World Decision Framework
Here is how experienced Salesforce architects make the call in practice:
- Need to make a callout after a record save?
Use @future(callout=true) for simple cases, Queueable with callout support for anything more complex.
- Need to update 50,000+ records overnight?
Use Batch Apex with a QueryLocator. Let the platform handle chunking.
- Need to run a multi-step process where step 2 depends on step 1’s output?
Use chained Queueables. Pass state through constructor parameters.
- Need to run something every night at 2 AM?
Use Scheduled Apex to trigger a Batch job. Do not put business logic in the scheduler itself.
- Need to process records from a trigger without hitting limits?
Use a Queueable from the trigger. Avoid @future if you need to pass sObjects.
Conclusion
The four Salesforce asynchronous processing mechanisms are not interchangeable, and each was designed with a specific problem in mind. Reaching for the wrong one leads to governor limit errors, unmaintainable code, and scalability ceilings that only reveal themselves in production.
The mental model is simple: use @future for quick callouts, Queueable for complex chained logic, Batch for mass record processing, and Scheduled Apex as a time-based trigger that delegates to the others.
Mastering these four tools and knowing exactly when each one is the right choice is one of the clearest markers of a senior Salesforce developer. Build with the right tool, and your async architecture will scale cleanly as your org grows.
FAQs
What is an asynchronous process in Salesforce?
Asynchronous processing allows you to get more stuff done in the same amount of time. Asynchronous Apex is great for callouts to external systems, operations that require higher limits, and code that needs to run at a certain time.
What is an example of asynchronous processing?
A typical application area for asynchronous processing is online inquiry on remote databases; for example, an application to check a credit rating. A terminal operator can use a local transaction to enter a succession of inquiries without waiting for a reply to each individual inquiry.
What are the SOQL limits for Batch Apex?
For Batch Apex, there are no SOQL limitations as developers can use up to 200 queries within Batch Apex execution compared to other processes in synchronous Apex. In addition, since Batch Apex executes in separate transactions, such limits will be set for each transaction and not per execution.
How many Batch Apex jobs could be executed at the same time in Salesforce?
Currently, Salesforce allows the developers to execute up to 5 concurrent Batch Apex jobs at once. All subsequent Batch Apex jobs will remain queued until an earlier job finishes.
How do developers monitor Queueable and Batch jobs?
Developers can use a returned Job ID to monitor the status of Queueable jobs. Moreover, the developers can monitor them using ApexQueryId by utilizing Setup or SOQL queries. Batch Apex allows users to monitor their batches by using ApexJobId.
For more insights, updates, and expert tips, follow us on LinkedIn.
