Asynchronous Calls
An asynchronous call in Salesforce is an Apex operation that runs later, in a separate transaction from the code that started it.
Definition
An asynchronous call in Salesforce is an Apex operation that runs later, in a separate transaction from the code that started it. The calling transaction does not wait for the result. It returns right away, and the platform runs the queued work whenever processing resources become available, which can be milliseconds or minutes afterward.
Salesforce groups asynchronous Apex into four patterns: future methods (the @future annotation), Queueable Apex, Batch Apex, and Scheduled Apex. Each pattern has its own entry point, its own monitoring, and its own behavior under load. They share one purpose. Move work out of the synchronous request so the user is not blocked, large data volumes can be processed, and operations get a fresh set of governor limits instead of competing inside one tight transaction.
The four asynchronous Apex patterns and when each fits
Why asynchronous processing exists
A synchronous Apex transaction runs inside hard governor limits. You get 100 SOQL queries, 150 DML statements, 6 MB of heap on a synchronous request, and a short CPU budget. Those ceilings protect the multitenant platform, but they break on real workloads such as recalculating a million records or waiting on a slow external system. Asynchronous Apex is the escape hatch. The platform takes your queued job and runs it on the Asynchronous Apex queue when resources free up, against its own limit allocation. Salesforce lists three benefits in its overview docs: user efficiency, because the user is not stuck waiting for a long task; scalability, because more work can run across more resources; and higher governor limits, because async transactions get larger ceilings than synchronous ones. The trade is timing. You cannot predict the exact moment an async job runs, and the caller does not receive a return value. So async is the right tool when the work can finish out of band and does not need an immediate answer back to the user interface.
Future methods (@future)
A future method is the oldest async pattern and the simplest to write. You annotate a static method with @future, and Salesforce runs it in its own transaction when resources are available. The rules are strict. The method must be static, must return void, and can only accept primitive data types, arrays of primitives, or collections of primitives. You cannot pass an sObject directly, because the record could change between the call and the execution. The common workaround is to serialize records to JSON, pass the string, then deserialize inside the method. To make an HTTP callout from a future method, add the callout=true parameter to the annotation. Future methods are fire-and-forget. The caller gets no job ID and no result, so monitoring is limited. They also cannot be chained: a future method cannot invoke another future method, and you can issue no more than 50 future calls per Apex invocation. Salesforce now recommends Queueable Apex over future methods for most new work, because Queueable does everything @future does and adds capabilities that future methods lack.
Queueable Apex
Queueable Apex is the modern replacement for future methods. You implement the Queueable interface with a single execute method, then submit the job with System.enqueueJob. That call returns an AsyncApexJob ID, so you can monitor the job and query its status. Unlike future methods, a Queueable class can hold member variables of any type, including sObjects and custom Apex objects, because the state travels with the instance. Queueable jobs also support chaining. One job can enqueue the next from inside its execute method, which lets you break a multi-stage process into ordered steps. Chaining has a guardrail. In Developer Edition and Trial orgs the maximum stack depth is 5, meaning you can chain four times after the parent. You can also add up to 50 jobs to the queue with System.enqueueJob in a single transaction. Newer releases added the AsyncOptions and AsyncInfo classes, which let you set a maximum chain depth and a minimum delay before a queued job runs, and read the current depth at runtime. For one-shot heavy work or a short ordered pipeline, Queueable is usually the best choice.
Batch Apex
Batch Apex is built for large data volumes that no single transaction could handle. You implement the Database.Batchable interface, which defines three methods. The start method returns the records to process, usually as a QueryLocator that can hold up to 50 million rows. The execute method runs against one chunk of those records at a time. The finish method runs once at the end for cleanup or notification. The platform splits the full record set into batches, with a default scope of 200 records per execute call, and runs each chunk in its own transaction. That is the key advantage. Every chunk gets a fresh set of governor limits, so a job can sweep through millions of records without tripping a single-transaction ceiling. The execute calls within a job run synchronously relative to each other, so they do not collide. When the Apex Flex Queue is enabled you can submit up to 100 batch jobs in the Holding state, and they move into the active queue as slots open. Reach for Batch when the row count is in the tens of thousands or higher.
Scheduled Apex
Scheduled Apex runs Apex on a recurring schedule rather than in response to a user action. You implement the Schedulable interface, which has one execute method, then register it with System.schedule. That call takes a job name, a CRON expression, and an instance of your class. The CRON expression sets the cadence down to seconds, but the platform enforces a minimum frequency of roughly one hour between runs, so you cannot schedule a class to fire every minute. A very common production pattern is to keep the scheduled class thin and have its execute method submit a Batch job. That combination gives you cron-style timing plus the chunked, high-volume processing of Batch Apex in one design. Scheduled jobs appear in Setup under Scheduled Jobs, where you can view and delete them, and each run also creates an AsyncApexJob record. Use Scheduled Apex for nightly data hygiene, weekly rollups, periodic integration syncs, or any task that should happen on the clock instead of on demand.
Governor limits and the shared 24-hour cap
Asynchronous transactions get more generous governor limits than synchronous ones. The SOQL query ceiling rises to 200, the heap doubles to 12 MB, and you get a longer CPU budget, which is precisely why heavy operations belong in async. Each async transaction, whether that is a Batch chunk or a single Queueable execution, gets its own fresh allocation rather than sharing one pool. There is a separate ceiling that catches teams by surprise. The total number of asynchronous Apex executions in a rolling 24-hour window is capped at 250,000, or the number of user licenses in your org multiplied by 200, whichever is greater. That cap is shared across all four patterns. Batch, Queueable, Scheduled, and future invocations all draw from the same daily pool. A noisy trigger that fires a future call on every record update can quietly burn through the allotment and start failing other jobs. Design for this. Bulkify so one transaction enqueues one job for many records instead of one job per record, and watch the daily count in orgs that run a lot of automation.
Monitoring, ordering, and choosing a pattern
Every async pattern except fire-and-forget future calls produces an AsyncApexJob record, which you can query for status, type, completion date, and error counts. The Setup Apex Jobs page shows the same data with batches processed and any error message, and an uncaught exception triggers an Apex Exception Email to the developer who last edited the class. Ordering trips people up. The platform does not guarantee jobs run in submission order; a Queueable chain preserves order within that one chain, but two independent jobs can run in either sequence. AsyncApexJob retention is a short rolling window, so log failures to a custom object when you need durable history. To pick a pattern, start from the work. A trigger that must call out uses Queueable with callouts or a future method with callout=true. A heavy one-shot job or short ordered pipeline uses Queueable, chained if stages depend on each other. Tens of thousands of records or more use Batch. A clock-driven task uses Scheduled Apex, often submitting a Batch job. When two options both fit, prefer Queueable for its job ID, sObject support, and chaining.
Trust & references
Cross-checked against the following references.
- Asynchronous Apex | Apex Developer GuideSalesforce
- Queueable Apex | Apex Developer GuideSalesforce
Straight from the source - Salesforce's reference material on Asynchronous Calls.
- Future Methods | Apex Developer GuideSalesforce
- Use Batch Apex | Apex Developer GuideSalesforce
- Apex Scheduler | Apex Developer GuideSalesforce
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 Apex feature is the modern preferred alternative to a Future asynchronous method?
Q2. Why does a trigger pushing an external callout into an asynchronous call avoid an error?
Q3. Which statement about governor limits in an asynchronous call transaction is correct?
Discussion
Loading discussion…