This guide will help you evaluate the right approach for your asynchronous processing requirements on the Salesforce platform. It explains each approach, detailing the strengths and limitations of each. Most approaches are aligned with a product feature, but some approaches use multiple features in coordination. The guide includes use cases to highlight when to use each approach.

Asynchronous processing provides two major benefits for your architecture. First, it increases scalability because asynchronous processes have higher governor limits. Second, asynchronous requests execute in their own threads so users can do other work while the asynchronous tasks execute in the background.

Note that this guide focuses exclusively on choosing an asynchronous processing technology within the Salesforce Platform. Other resources to help your decision process are listed in the Resources section.

Salesforce Platform The Salesforce Lightning Platform is a comprehensive, AI-driven platform that unifies employees, autonomous AI agents, company data, and applications into a single, trusted system to enhance productivity and customer experience. It enables the creation of an "agentic enterprise" by connecting Customer 360 apps, Data Cloud, and Slack for end-to-end automation.

This document does not cover technologies in other ecosystems such as MuleSoft, Informatica, Commerce Cloud, Tableau, and Marketing Cloud.

  • Before using asynchronous processing, make sure that your use cases fit the pattern. Asynchronous patterns have no SLA, are subject to multiple governor mechanisms, can have capacity limits defined based on licensing, and can cause processing delays due to the finite nature of the resources allocated to asynchronous infrastructure within the Salesforce Platform. Consider these limitations when using asynchronous processing in scenarios where a user requires a response from the system before they can continue with their work.
  • Asynchronous processing with Salesforce isn’t a solution for boundless scaling needs. The Salesforce Platform doesn’t scale infinitely, and asynchronous patterns are subject to limitations. Asynchronous processing uses threads, which contain the contextual information that a CPU needs to execute a stream of instructions. Threads can run in parallel. The number of available threads in any CPU is limited, so the platform has mechanisms in place to use its available threads as efficiently as possible. The platform’s flow control mechanism prevents orgs from consuming too many threads and negatively affecting other orgs. The platform’s fair usage algorithm also controls the number of threads that an org has available for each particular message type.
  • Account for events that can cause extreme loads. When you design asynchronous processes, make sure they can predictably manage workload spikes and lulls. Consider how your implementation handles unexpected events, such as power outages, and design safeguards that mitigate data loss or loss of functionality.

This table outlines the tools that are available for asynchronous processing with Salesforce. Refer to this table to review each tool’s major characteristics during your decision-making process. See Use Cases and Decision Points for help choosing the right tools for your architecture.

Approach Description Skills Required Licenses and Limits
Queueable Apex Use for processes that involve long-running database operations or external web service callouts. Queueable Apex offers features such as job IDs, support for non-primitive types, and job chaining. Pro-code The number of licenses can increase the limits.
Batch Apex Build complex, long-running processes that involve millions of records by dividing your record set and processing it in manageable chunks. Pro-code The number of licenses can increase the limits.
Scheduled Apex Execute Apex at a scheduled time defined by a cron expression. Although the act of scheduling Apex via the cron expression is an asynchronous process, the underlying code executes synchronously when the job starts. Pro-code The number of licenses can increase the limits.
Apex Continuation Callouts Execute callouts from Apex methods running in a synchronous transaction context. Pro-code No
Asynchronous Path (Record-Triggered Flows) Execute an operation that you want to run on its own time. Avoid mixed DML errors that occur when you update a value on a related record that isn’t part of the record that triggered a flow. Low-code The number and type of licenses can increase the limits.
Scheduled Path (After Commit Flows) Execute at a dynamically scheduled time after a triggering event, such as when a record is created, updated, or deleted. Low-code The number and type of licenses can increase the limits.
Scheduled Flows Execute a flow in the background at a specified time and at a repeated frequency (daily, weekly, or once) to perform actions on a batch of records. Low-code The number and type of licenses can increase the limits.
Platform Event Triggers Loosely couple Salesforce with external systems and communicate between asynchronous components within the Salesforce Platform. Low-code + Pro-code An add-on license is required for high-volume platform event use cases
Change Data Capture Capture and process change events asynchronously after the database transaction is committed. Pro-code An add-on license is required to scale above baseline allocation.
Bulk API Insert, update, upsert, query, or delete many records asynchronously and process the results later. Pro-code There are limits.
Lightning Actions Allow Lightning pages to interact with the server without forcing users to fully refresh the page. Low-code No

This table contains an overview of points to consider as you decide which asynchronous tool to use.

Skills Required Some of the tools outlined in this guide require code, while others can be configured declaratively. As you consider your options, think about the skillsets that your team members have. Keep in mind that even if developers are available for your initial implementation (through an implementation partner, for example), you may need to modify your solutions in the future. If your maintenance team lacks developers, a low-code option can be a better fit.
Type of Platform Limits Enforced Determine the type of limits that apply to the execution. As you design your solutions, think carefully about how the volume and frequency of transactions will count toward the governor limits for the chosen approach each day. Calculate the number of executions that will occur each day. Make sure that the calculated values fall within the limits associated with your selected tools.
Latency Determine how quickly the results of processing will be available in the platform. For some approaches, the changes will be nearly immediate, whereas for others it may be minutes or hours.

When you select a tool for asynchronous processing, first evaluate your organization’s requirements and available resources. Your goal is to select the tool or tools that minimize implementation and maintenance costs, but still ensure scalability and minimize your likelihood of limit violations. This goal is dependent on the technical considerations outlined previously, as well as the makeup of your team.

Consider an asynchronous ordering process in Salesforce. When an order is saved, it triggers a message to an external warehouse management system with special instructions for how to pack and ship an item. The user who places the order doesn’t need an immediate response from the warehouse management system, so the request can be sent asynchronously. The asynchronous processing allows the user to continue their work without waiting for a response.

For this use case, you might consider implementing with Apex. This approach will only work if you have Apex developers on your team who can maintain your pro-code solution. Otherwise, a declarative approach makes more sense. Also, keep in mind that different sets of limits apply to different tools.

This table lists common use cases in the left-most column, followed by a description. The First Choice column provides the most typical approach used to satisfy such a use case, along with the rationale for the First Choice approach. Use this as a starting point in your analysis—the First Choice approach may have limitations that will not work for your use case.

Use Case Description First Choice Approach Rationale
High-performance batch processing Any automation that must process thousands or millions of records efficiently Batch Apex Batch Apex provides rich APIs for interfacing with the platform and for raw speed.
Data Cleansing Job A job that runs routinely, or on demand, that cleans data. Examples include de-duplication, address verification, or data consolidation. Batch Apex Batch Apex provides rich APIs for interfacing with the platform and for raw speed.
Nightly Rollup Job Job that computes rollup data at the end of a business day. Batch Apex Batch Apex provides rich APIs for interfacing with the platform and for raw speed.
Record-Triggered Logic Execute logic in response to a record update. Varies See our companion decision guide, Record Triggered Events Automation. It includes a decision tree for asynchronous use cases, including Queueable Apex, Batch Apex, Scheduled Apex, Scheduled Flow, Async Path Flows, and Change Data Capture.
Cascading Updates Through an Object Graph Allows a user’s save action to complete quickly, deferring cascading updates to other objects to run asynchronously. Queueable Apex Queueable Apex has powerful chaining features that enable logic to divide a chain of updates into a series of asynchronous transactions.
Record-Specific Scheduled Processing Automation at a future, dynamic date specific to the record (for example, 3 days before a close date). Flow with a Scheduled Path Scheduled paths provide a unique strength to Flow, as the platform automatically handles the scheduling, cancellation, and rescheduling of these paths if the record's data changes.
Invoking Multiple Slow External Services in Parallel During a synchronous execution, multiple external services are invoked in parallel to optimize overall execution time. Apex Continuation Callouts Allowing multiple slow-running callouts to run in parallel minimizes the overall time to complete the work.
Data Migration of Records from an External System Move large amounts of records into the Salesforce Platform from an external system. Either a one-time or regularly scheduled process. Bulk API This is the most efficient and limit-friendly approach for data migration.
Execute Additional Logic on an External System Fire-and-forget pattern of notifying an external system of an event on the platform, then allowing that system to asynchronously process the event. Platform Events or Change Data Capture A pub-sub model works best here, and allows the external system to process the event when it is ready. See Event-Driven Architecture for more details on this pattern.

The Use Cases table is a guide toward the best-fit approach for each use case. However, you’ll need to validate how well the First Choice technology fits the specific needs of your use case. In particular, determine whether the chosen approach can adhere to the governor limits for your org.

Once you have identified a candidate approach for your use case, the Asynchronous Processing Fundamentals Guide can assist in fully vetting the solution.

These additional resources can help with your decision process: