Asynchronous Calls
Asynchronous Calls in Salesforce Apex are operations that run on the platform later, in a separate transaction from the code that triggered them.
Definition
Asynchronous Calls in Salesforce Apex are operations that run on the platform later, in a separate transaction from the code that triggered them. The calling transaction returns immediately and the async work happens whenever the platform schedules it (milliseconds to minutes later). Four asynchronous patterns dominate: Future methods (@future annotation, fire-and-forget), Queueable Apex (Database.queueable for more control plus chaining), Batch Apex (for large data volumes processed in chunks), and Scheduled Apex (Schedulable interface for cron-style runs). Each pattern has its own constructor, its own governor limits, and its own monitoring surface; choosing the right one is most of the design work.
Async calls exist because the synchronous transaction has tight limits (100 SOQL queries, 10 callouts, 10000 DML rows, 6 MB heap) that quickly fail on real workloads. Anything that needs more, or needs to wait for an external system, or needs to fire after the user's UI thread returns, gets pushed into async. The platform's Asynchronous Apex queue runs these jobs against larger limits, with more concurrency, and with their own retry behaviour on failure. For developers, the design discipline is to spot the work that fits async, pick the right pattern, and respect the per-transaction limits that even the async layer enforces.
The four asynchronous Apex patterns and when to use each
Future methods (@future)
The simplest async pattern. Annotate a static method with @future to make it fire-and-forget. The caller does not get the result back. Future methods are useful for HTTP callouts from triggers, where the trigger context forbids synchronous callouts. Limitations: no method chaining, no parameters beyond primitives and collections, and the calling transaction loses visibility into the async outcome.
Queueable Apex
Queueable is the modern preferred alternative to Future. Implement the Queueable interface, enqueue with System.enqueueJob, and the platform runs the job asynchronously. Queueable supports parameters of any sObject type, supports chaining (one Queueable can enqueue another), and returns a job ID for monitoring. Most new async work should be Queueable, not Future.
Batch Apex
Batch Apex is built for large data volumes. The Database.Batchable interface has start, execute, and finish methods. The platform queries a record set, splits it into chunks (default 200), and runs execute against each chunk in its own transaction. Each chunk gets fresh governor limits, which lets Batch process millions of records that synchronous Apex cannot touch.
Scheduled Apex
Scheduled Apex runs on a cron schedule. Implement Schedulable, then System.schedule with a cron expression sets up the recurring run. Most production usage of Scheduled Apex submits a Batch job from inside the scheduled execute method, combining cron scheduling with batch processing.
Governor limits in async context
Async transactions get larger limits than synchronous ones: 200 SOQL queries instead of 100, 12 MB heap, 200 callouts, 60 seconds CPU. The increased limits are why heavy operations belong in async. Each transaction (batch chunk, queueable execution) gets its own fresh allocation.
Concurrency, ordering, and chaining
Salesforce caps concurrent batch jobs at five and queueable depth at a few hundred chained jobs. Order is not strictly guaranteed; a queued job can run before another submitted earlier if the platform reorders. Chains preserve order within the chain but not across chains. Production patterns use job IDs and the AsyncApexJob object to track state.
Monitoring and failure handling
The Apex Jobs page surfaces every async execution with status, errors, and elapsed time. Apex Exception Email fires on uncaught errors. AsyncApexJob records persist for a rolling window. Production teams build dashboards on AsyncApexJob to track health and alert on failure spikes.
Choosing between the patterns
Trigger needs to make a callout: Future or Queueable. Heavy one-shot job: Queueable, chaining if multi-stage. Millions of records: Batch. Recurring schedule: Scheduled Apex submitting Batch. Real-time event response: Platform Events with Apex trigger, not strictly async but operationally similar.
How to pick and implement the right async pattern
Async design is mostly choosing the right pattern. The implementation is straightforward once the choice is made; the failures come from forcing one pattern when another fits better.
- Identify what cannot run synchronously
Callouts from triggers, processing more than a few thousand records, long-running calculations, anything the UI thread should not wait for. These are async candidates.
- Pick the pattern
Trigger callout: Future or Queueable. Heavy one-shot: Queueable. Bulk data: Batch. Recurring: Scheduled Apex submitting Batch. Document the choice; future maintainers benefit from the reasoning.
- Implement with sane error handling
Wrap risky operations in try/catch. Log failures to a custom error object so they survive past Apex Jobs retention. Async failures are easy to miss without explicit logging.
- Test against representative data
Async jobs that pass in a 10-row dev org can fail at scale. Run tests against full-volume sandboxes with realistic data shapes before promoting to production.
- Monitor in production
Build a dashboard on AsyncApexJob. Watch for failure spikes, long-running jobs, and queue saturation. Catch issues before users do.
- Future methods cannot accept complex sObject parameters; they accept only primitives and primitive collections. Queueable supports any sObject.
- Async limits are larger than sync but still real. A Queueable that touches 100,000 records still needs careful bulkification.
- Async failures are easy to miss without explicit logging. AsyncApexJob retention is weeks; persistent logging requires a custom object.
- Chaining queueable jobs has a depth limit. Production patterns use chunked submission with explicit IDs to avoid running into the chain limit.
Trust & references
Cross-checked against the following references.
- Asynchronous ApexApex Developer Guide
- Queueable ApexApex Developer Guide
Straight from the source - Salesforce's reference material on Asynchronous Calls.
- Monitor Apex JobsSalesforce Help
Hands-on resources to go deeper on Asynchronous Calls.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Which of these is NOT a type of asynchronous Apex?
Q2. What is a main advantage of using asynchronous processing?
Q3. What is a common risk when using asynchronous code?
Discussion
Loading discussion…