Our forward-looking statement applies to roadmap projections.

Roadmap corresponds to June 2025 projections.

Guide Overview

Asynchronous processing increases scalability by allowing higher limits per context, as asynchronous requests execute in their own threads behind the scenes, without users having to wait for them to complete before moving on to other work.

We commonly use the phrase “Fire and Forget” to refer to patterns that involve asynchronous processing. These patterns can improve user experiences by enhancing UI responsiveness since users can continue to do work on the client side while related tasks execute in the background.

To visualize what this might look like in Salesforce, consider an asynchronous ordering process. 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. Since the user placing the order doesn’t need an immediate response from the warehouse management system, the request can be sent asynchronously, allowing the user to continue their work without delays.

Three important things to keep in mind, however, are:

1. Asynchronous processing is not the best approach for every problem. It can be tempting to think of any process that doesn’t directly require user interaction to be a good candidate for asynchronous processing, but there are some additional considerations. First, that asynchronous processes have no SLA, which means that there’s no guarantee that an async process will complete within a set amount of time. Second, there’s no guarantee of consistent response latency. Just because an asynchronous process completes within a certain amount of time doesn’t mean that subsequent processes will also finish within that amount of time. Even if a user isn’t directly waiting for a response, if you have follow-on processes that are waiting for one or if you’re concerned that excessive response times might cause your data to become out of sync with the data in an external system, you should reconsider whether asynchronous processing is right for your scenario.
2. There are different ways to process asynchronous requests on the Salesforce Platform and you need to make sure that you’re choosing the best approach. Tools that support asynchronous processing on the Salesforce Platform work differently “under the hood” and some were designed for very specific use cases.
3. When a tool is asynchronous on the client side, it does not necessarily follow that all of the end-to-end processing is going to be performed in parallel: Depending on the choices you make, the client's messages might still get serialized on the server side.

Using the wrong tools, or the wrong combinations of tools for the wrong jobs can have unintended consequences that cancel out the benefits that asynchronous processing may have provided. This guide provides explanations and recommendations, as well as potential drawbacks and anti-patterns for various asynchronous use cases along with the rationale for those recommendations. It also provides insight into how various asynchronous implementation techniques operate and are regulated on the Salesforce core platform.

Note that this guide focuses exclusively on asynchronous processing within the core Salesforce Platform. If you are looking for information about asynchronous integration patterns, make sure to check out the Architect’s Guide to Event-Driven Architecture.

Key Takeaways

• Takeaway #1: Before using asynchronous processing, make sure your use cases are valid. Asynchronous patterns have no SLA, are subject to multiple governor mechanisms, and can cause processing delays due to the finite nature of the resources allocated to asynchronous infrastructure within the Salesforce Platform. Take this into serious consideration when using asynchronous processing in scenarios where a user requires a response from the system before they can continue with their work.
• Takeaway #2: Asynchronous processing with Salesforce is not a solution for horizontal scaling needs. The Salesforce Platform does not scale infinitely and asynchronous patterns are still subject to limitations. Asynchronous processing utilizes threads, which contain the contextual information a CPU needs to execute a stream of instructions and can run in parallel. The number of available threads in any CPU is limited, so the platform has mechanisms in place to ensure that its available threads are utilized 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 controls the number of threads that an org has available for each particular message type.
• Takeaway #3: Know when transactions are truly asynchronous. Some architecture patterns behave asynchronously end-to-end, while others behave asynchronously on the client (browser) side, while serializing server-side requests, which are then subject to synchronous governor limits.
• Takeaway #4: If you have to build large-scale outbound integrations from the core Salesforce Platform, use platform events and robust middleware instead of callouts via asynchronous Apex. Since there are a finite number of asynchronous threads available in the platform, outbound integrations via asynchronous Apex will have limited scalability. If your org has outbound integrations that involve high volumes of messages, exceed the number of available threads, and have long processing times, then using asynchronous Apex will inevitably introduce delays.
• Takeaway #5: Make sure to incorporate monitoring when using asynchronous processing. Monitoring enables you to detect issues as early as possible and correct them before major performance incidents occur.

Tools for Asynchronous Processing with Salesforce

The table below outlines the tools that are available for asynchronous processing with Salesforce. This guide will dive deeper into how to choose between these tools in the following sections, but you can refer to this table for each tool’s major characteristics during your decision-making process.

Decision Points At-a-Glance

The table below contains an overview of the decision points that you'll want to think about when making your tool selections, along with questions you should be asking yourself about each one.

Server-Side Asynchronous Processing

When choosing the right tool for server-side asynchronous processing, start by evaluating your organization’s requirements and available resources. Your goal is to select the tool or tools that will keep your implementation and maintenance costs to a minimum, while also ensuring scalability and minimizing your likelihood of limit violations. This will be dependent on the technical considerations outlined in the tables below, as well as the makeup of your team (do you have Apex developers on staff who can maintain your solution or would a declarative approach make more sense?). Also note that different tools are enforced by different sets of limits.

Questions to ask:

• How many concurrent processes are needed?
• How many SOQL queries will execute within each process?
• How long will each process run?

Asynchronous Apex

The Salesforce Platform’s multitenant architecture isolates and concurrently supports the varying requirements of many tenants (orgs). All asynchronous Apex methods covered in this guide are executed within the same asynchronous infrastructure in the Salesforce Platform. They use a message queueing framework that is governed by two primary enforcement mechanisms: flow control and fair usage.

The purpose of flow control and fair usage is to prevent a single tenant from using too many server resources and not leaving enough for the remaining tenants. While it's good to understand how these mechanisms work, your key takeaway should be that following best practice guidelines for asynchronous processing (such as the ones outlined in the sections below) will significantly reduce your likelihood of running into issues with them.

Flow Control

The platform’s flow control mechanism prevents one org from flooding a given message type, consuming too many threads and negatively affecting other orgs. Prior to adding new entries to the queue associated with a message type, the framework will check the first several thousand existing entries in the queue to see if other orgs have work to be done. If the majority of existing entries are associated with a single org that already has entries in worker threads, the newly added entries will be moved to the back of the queue (a process called re-enqueuing). This typically happens to Batch Apex and Bulk API processes, as they tend to insert large numbers of entries into their queues at once.

Message Re-Enqueueing

Fair Usage

The platform’s fair usage algorithm implements a tier-based system that ensures that each org on the Salesforce Platform gets a “fair share” of processing time on a given message type (i.e. Future, Queueable, Batch). If one org is dominating a given message type and other orgs are waiting to perform work on the same message type, the fair usage algorithm will reduce the number of threads that org has available for that particular message type.

Fair Usage Algorithm

A benefit of using asynchronous Apex methods is that some governor limits, such as SOQL query limits and heap size limits are higher. However, you shouldn’t rely too heavily on these methods. Due to the finite nature of the resources allocated to asynchronous infrastructure, heavily using Future, Queueable, and Batch Apex can cause processing delays that stem from limitations based on fair usage and flow control.

Special Considerations for Outbound Callouts via Asynchronous Apex

Outbound callouts that use asynchronous Apex are counted against the asynchronous Apex limit. The daily limit is currently 250,000 or 200 times the number of user licenses, whichever is greater. This can be an issue for high-volume use cases. If you exceed the limit, your asynchronous Apex jobs and their associated outbound callouts will fail.

Additionally, since the platform has a finite number of asynchronous threads available, outbound integrations via asynchronous Apex will have limited scalability in general, as any outbound integrations involving high volumes of messages that exceed the number of threads and have long processing times will lead to delays.

For high-volume use cases, consider the alternative approaches outlined below. API calls with these approaches count towards the daily API request limit, which is currently 5000 for every user license. This is a significantly higher limit and will be much more scalable than asynchronous Apex. Note, however, that there are still physical limitations on the number of concurrent requests that any CPU can process. Regardless of which pattern you use, it’s always best to limit concurrent requests to < 200 per second in order to avoid throttling.

• Middleware Scheduled Pull. You can avoid delays associated with high-volume outbound integration jobs by using middleware to pull the data on a scheduled basis instead of pushing it via asynchronous Apex. Middleware (such as the MuleSoft Anypoint platform) can use native SOAP API or REST API in a synchronous fashion that will introduce very few (if any) delays. Middleware can also use the native Bulk API for very large data volumes.

Middleware Scheduled Pull

• Middleware Pull via Platform Event Notification. Instead of enqueuing Future/Queueable/Batch asynchronous Apex to perform outbound integrations, you can use platform events to either deliver the outbound information itself or instruct a middleware tool to pull the required information via a native API and deliver it to its final destination. Both approaches are synchronous and are not subject to the same delays that asynchronous Apex is subject to. However, it is important to note that they are still subject to platform event limits.

Middleware Pull via Platform Event Notification

Asynchronous Apex Tradeoffs

Apex Future Methods and Apex Queueable

You can call a future method to execute long-running operations, such as callouts to external web services, or operations that need to run in their own threads, on their own time. Each future method is queued and executes when system resources become available. This ensures that your code’s execution will not have to wait for the completion of a long-running operation.

Apex Queueable is an enhanced way of running asynchronous Apex (compared to using future methods), and should be your preferred approach. You can run Apex processes that involve extensive database operations or external web service callouts asynchronously by implementing the Queueable interface and adding a job to the Apex job queue. This will ensure that the asynchronous Apex job will run in the background in its own isolated thread and won’t delay the execution of your main Apex logic. Just like with future methods, each queued job runs when system resources become available. Queueable jobs provide some additional benefits as well:

• Job IDs: When you submit a job by invoking the System.enqueueJob method, the method returns the ID of the new job. You can use this ID to identify your job and monitor its progress through the Apex Jobs page in the Salesforce UI, or by querying the AsyncApexJob object.
• Support for non-primitive types: Queueable classes can contain member variables of non-primitive data types, such as sObjects or custom Apex types.
• Support for job chaining: You can chain Queueable jobs together by starting a second job from a running job. This technique can help you address scenarios involving process dependencies.
• Transaction finalizers: You can attach a post-action sequence to a Queueable job and take relevant actions based on its result. For example, a transaction finalizer can re-enqueue a Queueable job that failed due to an unhandled exception up to five times.

Considerations for Apex Future Methods and Apex Queueable

Salesforce uses a queue-based framework to handle asynchronous processes. This queue is used to balance request workloads across organizations. In order to ensure that your organization is using this queue as efficiently as possible, you should:

• Avoid enqueueing future or Queueable methods directly from actions generated by large volumes of end-user activity or integration API calls. This approach can quickly exhaust daily asynchronous Apex limits, resulting in serious business impacts.
• Avoid enqueueing more than one asynchronous action per synchronous action. When multiple asynchronous methods are enqueued from a single synchronous action, the asynchronous activities often execute at the same time and contribute to row lock contention and/or row lock timeout errors.
• Avoid adding large numbers of future or Queueable methods to the asynchronous queue. If more than 2,000 unprocessed requests from a single org are in the queue, any additional requests from the same org will be delayed while the queue handles requests from other orgs.
• Ensure that future and Queueable methods execute as quickly as possible. The longer a future method takes to execute, the more likely requests behind it in the queue will be delayed. To ensure fast execution of batch jobs, minimize web service callout times, tune queries used in your future methods, and optimize any other object automations including Process Builder processes, workflow rules, flows, and Apex triggers.
• Test your asynchronous methods at scale. Use an environment that generates the maximum number of methods you would expect to handle. This will help determine if you’ll encounter issues with performance or limits in your production environment.
• Use Batch Apex instead of future or Queueable methods to process large numbers of records. Batch Apex can handle complex, long-running processes that execute against thousands of records and can be scheduled to run during off hours when more resources are available.

Apex Continuations

Historically, synchronous callouts made from an Apex method running in a synchronous Apex transaction context (for example, a Visualforce controller or Lightning controller) would be counted toward the Apex concurrency limit of 10 synchronous requests that are longer than five seconds in duration. As of Winter ’19, synchronous callouts are no longer counted as long-running. Apex continuations were initially created as a solution to synchronous callouts that resulted in long-running requests, but they also provide some additional benefits:

• A single synchronous action can perform up to three continuation actions (the previous continuation must complete prior to a new continuation action being performed).
• Each continuation action can perform up to a maximum of three callouts, which execute in parallel.
• When all of the callouts performed by a continuation action are complete, the platform invokes the continuation callback method to handle the results.

Considerations for Apex Continuations

While continuations execute asynchronously with respect to the originating synchronous action, they do not share anything in common with asynchronous Apex techniques such as future methods, Queueable, or Batch. Key differences are:

• Continuations are not queued in any way.
• Continuations do not contribute to the daily asynchronous Apex execution limit.
• Continuations switch thread context on the application server from a heavy-weight Apex platform thread to a lightweight thread that only performs callouts. For the purposes of executing callouts that may run up to 120 seconds, this represents significant application server memory savings.
• Originally, continuations could only be executed from a Visualforce JavaScript remoting call. However, in Summer ‘19, continuations were officially added to the Lightning framework, eliminating the need for Visualforce.

Platform Events

Platform events are the Salesforce Platform’s implementation of a purely event-driven architecture. You can find more details about the components associated with this type of architecture in the Architect’s Guide to Event-Driven Architecture.

Platform events and platform event triggers/flows are often great alternatives to running asynchronous Apex, such as future methods and Queueable. They’re also a great way to invoke off-platform processing. An example of this is using a combination of Amazon Web Services (AWS) event relays and platform events to invoke serverless compute functionality in AWS Lambda. If the work being performed is relatively fast and performs no callouts (which are not possible from a platform event trigger or flow), this could be a great use case for a platform event/trigger or event/flow combination.

Asynchronous Processing via Platform Events

The events published to the bus via publish after commit are delivered in order and can be bulk processed by the trigger or flow in a separate synchronous context. It is important to note that the context is synchronous and enforces all synchronous governor limits. Choose the platform event trigger/flow batch size carefully to avoid hitting limits.

Considerations for Platform Events

• As events are published on the event bus, they are available for consumers. In the case of event triggers (Apex or flow), these events are dispatched to available synchronous threads on the app tier (one thread per event trigger/flow). Note that this process does not have an SLA.
• When publish operations are added to the queue, the result of the queueing process is stored in the Database.SaveResult object. It’s important to note, however, that these entries only indicate whether or not the queueing operation was successful. If you want to get the final result of call published through the event bus, you can implement an Apex publish callback. Having this additional information will allow you make decisions about further actions that may need to be taken, such as attempting to republish failed events.
• While platform events are not subject to the same limits as asynchronous Apex, they do have their own sets of governor limits. If you run into issues with limits, you can enable enhanced event usage metrics to determine whether specific events are using up more of your allocations than you intended them to and determine the best corrective actions to take.
• If you need greater throughput on event triggers, it’s possible to create multiple identical platform events and triggers in order to provide more threads of execution for the incoming event load. Two possible patterns are applicable here:
  • Externally, event triggers can be evenly published for the various identical events (round-robin).
  • Alternatively, a single platform event trigger can round-robin publish multiple events in order to spread the load.

From a daily/hourly limit perspective, the first approach is more efficient as it simply consumes less platform event publish operations than the latter approach.

Roadmap Note: Beginning in Winter ’24, it will be possible to process multiple subscriptions simultaneously instead of a single subscription via Parallel Subscriptions for Apex Triggers.

• Platform events have two options for publish behavior:
  • Publish Immediately (Real-time): Events are published immediately during the transaction, before the final commit. Events that are published this way are not guaranteed to be published in order.
  • Publish After Commit (Non real-time): Events are published at the time the transaction is successfully committed. Events that are published this way are guaranteed to be published in order.

It is helpful to use real-time platform events for use cases such as logging, where you want to publish the logging event regardless of whether the transaction succeeds and commits, or fails and rolls back. However, real-time platform events must be used carefully and thoughtfully. It is possible to publish a real-time platform event that is consumed by a platform event trigger that competes for a database row lock with the transaction that published it. Review all designs thoroughly prior to publishing real-time platform events to ensure that this scenario is avoided.

Asynchronous Flows

Asynchronous flows provide low-code alternatives to asynchronous Apex. Just like with other forms of asynchronous processing, they execute in the background when resources are available but also have no SLAs and can have unpredictable wait times.

Scheduled Paths are cron-trigger based to execute at a specific time. They execute when records are created, updated or deleted and give you granular control over when to run the automation relative to the record change. (Example: send an email to a user one hour before a task is due.) Unlike Apex future methods, which are limited to a maximum of 50 enqueued in a synchronous transaction, scheduled flow actions do not currently have a max enqueue limit per transaction. There is however a batch size configuration within the definition of the scheduled path that allows for some control over how many records are handled by the scheduled path flow execution.

Asynchronous Paths can be added to record-triggered flows. They run in the background and won’t delay the execution of the transaction that originally triggered the flow. You can use an asynchronous path to execute a long-running operation, or any operation that you want to run on its own time. Asynchronous paths can help avoid mixed DML errors that occur when you need to update a value on a related record that is not part of the record that triggered the flow.

Outbound Messages

Note: Outbound messaging is a legacy feature, and while it is still a viable option for sending asynchronous messages, platform events (described in the previous section) are a more modern approach and offer greater flexibility.

Outbound messages provide a means of asynchronous outbound communication via SOAP API. When configured in Salesforce, the outbound message definition produces a SOAP WSDL that can be consumed by an external web service provider. Outbound messages can be triggered from workflow rules, Process Builder processes, or Lightning after-save flow triggers. An outbound message SOAP message can contain up to 100 notifications. Each notification contains the object ID and a reference to the associated sObject data. If the information in the underlying object changes after the notification is queued but before it is sent, only the latest data is delivered and not the intermediate changes.

When an outbound message listener (the web service you configured with the generated WSDL) receives a message, it uses the included session ID information to call the Lightning Platform API to update the record in Salesforce that triggered the outbound message.

Considerations for Outbound Messages

• Outbound messages are not handled via the queue-based asynchronous infrastructure in Salesforce that runs activities such as future methods, Queueable Apex, Batch Apex, Bulk API , and so on. Instead, records are stored locally in the OutBoundMessage object. Messages are dispatched and retried via a local scheduled background process.
• Messages are not sent synchronously when the outbound message action is executed by the initiating automation (for example, an after-save flow trigger). Instead, they remain in the OutboundMessage object until sent successfully or until they’re dropped after 24 hours of unsuccessful delivery.
• To avoid an infinite loop of outbound messages that trigger changes that in turn trigger more outbound messages, ensure that the user who updates the objects does not have the “Send Outbound Messages” permission.

Email-to-Case

Email-to-Case normally works in a synchronous manner. There are a limit of four synchronous threads to handle inbound Email-to-Case requests as the synchronous form of the handler actually maintains a connection to the inbound Salesforce mail server (MTA) that is receiving the email. However, there are a number of reasons why Email-to-Case would be handled in an asynchronous fashion:

• Email-to-Case is subject to thread limits, specifically 10 total handler threads per app server: four threads for synchronous processing and six threads for asynchronous processing.
• If a synchronous email handler exceeds 15 seconds of execution time, that particular email service address is marked as asynchronous for a period of 30 minutes. Subsequent handler requests for that service address will result in a message being enqueued for MessageTypeName = MAILCATCHER_EMAIL_TO_CASE, along with a reference to the email content.
• If a synchronous thread is already in use for a particular org and service address, additional requests for that service address are queued asynchronously.
• If a synchronously handled email encounters an error (for example, a row lock timeout), it is saved and queued asynchronously.
• If no synchronous handler threads are available, the request is queued asynchronously.

Considerations for Email-to-Case

• There is a deduplication option when configuring Email-to-Case, but it doesn’t deduplicate attachments until after the email has been processed. This saves space in the database, but it won’t reduce email processing times. You can, however, improve performance by implementing a custom Apex Email-to-Case handler for message processing. This won’t affect any governor limits, but it will give the handler access to the email message and all of its attachments before anything is committed to the database. This will allow you to compute checksums for all the included attachments and discard any that you decide are unnecessary, including duplicates, well-known signature pictures, or unwanted file types.
• Committing email attachments to FileForce is responsible for the majority of email processing time. As reply-responses to/from the contact increase and the email chain becomes larger, the processing time for each email will grow ever larger. If the email option “Reply with new content only” is not selected, email chains will grow with each reply and it is strongly recommended to use an Apex Email-to-Case handler with logic that implements attachment deduplication at the time of processing.
• Despite the invocation of Apex triggers as part of the handling, Email-to-Case handlers are exempt from the concurrent Apex limit.

Large Record Volume Processing

If you need to process large volumes of records asynchronously, use one of the approaches outlined below instead of the asynchronous Apex approaches described above, which are a better fit for lower volume processing. Keep in mind, however, that Batch Apex and the Bulk API are both subject to their own sets of limitations, which are described in this section.

Batch Apex

You can use Batch Apex to build complex, long-running processes that involve thousands of records. Batch Apex operates by dividing up your record set and processing it in manageable chunks. As an example, you can build an archiving solution that runs on a nightly basis and adds records older than a certain date to an archive. Or you can build a data cleansing operation that looks at all Accounts and Opportunities on a nightly basis and performs any necessary updates based on a set of predefined criteria.

Considerations for Batch Apex

• Batch Apex is best at processing large amounts of data due to the fact that asynchronous Apex has higher limits than synchronous Apex so that more work can be done. Batch Apex also performs more efficiently when it is processing more items per batch because it can use bulk operations and will incur less overhead from queue management. Because of this, you should avoid batches with small scope sizes or fast processing times to avoid consequences of flow control (queue flooding) and exhausting the daily asynchronous Apex limit.
• Batch Apex is limited to a maximum of five simultaneous threads, limiting its throughput much more than future methods or Queueable Apex.
• Batch jobs involving large volumes of data should ideally be scheduled to run during off peak hours in order to free up resources for processes that require real-time or near real time responses.
• When you call System.scheduleBatch, the platform will schedule your job for execution at the time you specify. Actual execution will occur on or after that time, depending on service availability.
• The scheduler runs in system context. All classes are executed, regardless of whether or not the user who scheduled the execution has permission to execute the class.
• All scheduled Apex limits apply for batch jobs scheduled using System.scheduleBatch. After the batch job is queued (with a status of Holding or Queued), all batch job limits apply and the job no longer counts toward scheduled Apex limits.
• Batch jobs enqueued from synchronous Apex transactions use the flex queue. The flex queue is limited to a maximum of 100 items at any one time. If a transaction attempts to add more entries, the platform will generate errors and will not submit the batch job.

Scheduled Flow

A Scheduled Flow is a flow scheduled to execute at a specified time and at a repeated frequency (daily, weekly, or once) to perform actions on a batch of records. (Example: update a field in all cases with a status of "Open" at 2am every night). Scheduled Flows are executed via the cron trigger mechanism and bulk processed.

Considerations for Scheduled Flows

• A scheduled flow executes 200 records per invocation, but will be executed with multiple concurrent threads if more than 200 records are present.
• Scheduled flows are executed in a synchronous context with synchronous limits.
• There is no way currently to control the number of records processed per scheduled flow invocation. If the execution is for more than 200 records, there is a real danger for Concurrent Apex errors as a result.

Bulk API and Bulk API 2.0

Bulk API is based on REST principles and is optimized for working with large sets of data. You can use it to insert, update, upsert, query, or delete many records asynchronously and process the results later. The Salesforce Platform will process the request in the background. In contrast, SOAP API and REST API use synchronous requests and are optimized for real-time client applications that update a few records at a time. You can use both of these APIs for processing many records, but when the data sets contain hundreds of thousands of records, they are less practical. Bulk API’s asynchronous framework is designed to make it simple and efficient to process data from a few thousand to millions of records.

The easiest way to use Bulk API is to enable it for processing records in Data Loader using CSV files. With Data Loader, you don’t have to write your own client app. Sometimes, though, unique requirements necessitate writing a custom app.

There are two Bulk APIs available within the Salesforce Platform.

• Bulk API 2.0 is the newer API. It provides a streamlined and easier-to-use workflow, and is the focus for enhancements.
• The original Bulk API is still fully supported, but is no longer being enhanced. We recommend that you use Bulk API 2.0 where possible.

The table below provides a comparison of the two:

Considerations for Bulk API

• If it takes longer than five minutes to process a whole batch, Bulk API 2.0 places the remainder of the batch back in the queue for later processing. If the API continues to exceed the five-minute limit on subsequent attempts, the batch is placed back in the queue and reprocessed up to 20 times before the batch is permanently marked as failed.
• Bulk API and Bulk API 2.0 both run in parallel mode by default. This means that multiple Bulk API batches performing CRUD actions will execute simultaneously. If more than one batch contains rows that have master-detail or lookup relationships to the same parent, the batches may compete with each other for row locks. Therefore, it is important to order the data in your Bulk API batches so that each batch contains records rolling up to the same parent. As Bulk API commits records 200 rows at a time, you can avoid row-locks by isolating parent/child pairs to separate batches.
• There are also a handful of cases where large amounts of data may always drive row lock contention and cannot be separated into separate batches to avoid row locks. The most common examples are bulk jobs that involve the Pricebook or Product objects. In these cases, the best approach is to specify Bulk API in serial mode. In these cases, the best approach is to specify Bulk API in serial mode. This will ensure that each batch will execute one at a time and will avoid potential row locks from other Bulk API batches that are submitted with jobs in serial mode. Note, however, that row locks can still occur from other Bulk API batches submitted with jobs in parallel mode, or from users using the UI. Also note that an org is limited to a maximum of one serial Bulk API job execution at a time.
• Bulk API allows the you to specify the batch size that Bulk API will utilize. This batch size will likely vary between jobs based on the nature of the objects, the operation, and the automation that underlies the object. It is important to tune the batch size so that it performs as much work as possible, but does not exceed 10 minutes of execution time per batch.
• When Bulk API is used improperly for small amounts of data, this batch limit can be consumed quickly and lead to integration-level failure. It is best to use native SOAP and REST APIs for small amounts of data and only use Bulk API when large amounts of data must be processed.

Client-Side Asynchronous Processing

While the platform handles the majority of asynchronous requests “behind the scenes” on the server side, tools that support asynchronous processing on the client side are also available. Note that client-side asynchronous processing is subject to the limitations of the browser or mobile application within which it is executing.

Questions to Ask:

• Will your client-side code be invoking Apex in any way? Apex synchronous governor limits will apply if so.
• Have you ensured that the payloads you’re sending to the server are as small as possible?
• Is your application using polling or timers? Make sure to set your polling intervals correctly and use $A.getCallback() to wrap code that modifies components outside of the normal rerendering cycle.

Lightning Actions (XHR requests)

All Lightning communications from the browser to the Salesforce Platform take the form of XMLHttpRequest (XHR) requests. This allows Lightning pages to interact with the server without having to fully refresh the page. Each of these actions results in a synchronous transaction context on the Salesforce Platform.

Considerations for Lightning Actions

• Lightning actions, despite being asynchronous with respect to the browser, are executed on the Salesforce Platform under a synchronous transactional context and are subject to synchronous limits. Standard Lightning actions may or may not invoke Apex on the Salesforce Platform. If Apex is invoked in any way during the Lightning action, the Apex synchronous governor limits will all apply during the transaction.
• When making requests to the server, it is best to send and receive as little data as possible in the payload. Every action by a user could potentially spawn multiple requests, and it is important that these be processed efficiently. Sending more data than necessary can contribute to slow transport and increased processing time on the client or server.
• When multiple components are listening for an application event, developers should ensure the event handler will only execute when it is actually desired and useful. For example, in the Lightning Console, components contained in tabs that are not focused can still be listening even though they are not visible. A developer can use various techniques such as using a background utility item as the only listener, or calling getEnclosingTabId() to determine whether this instance of the component is enclosed within the focused tab to ensure each event is handled only when it is intended.

Boxcar’ing in Lightning Actions

Lightning applications involve frequent communication to the Salesforce Platform to support the Lightning Framework. To support this, multiple requests can be issued at the same time, or “boxcar’ed” in a single XHR request to the Salesforce core platform. The maximum boxcar limit for Lightning is 2500 maximum actions per request. However, each of the boxcars within a request will be processed serially and in order in a separate transaction context. For example, if 100 custom Apex Lightning actions are boxcar’ed together and each takes four seconds to run, 100 separate Apex transactions will be executed on the Salesforce Platform under the same request, taking a total of 400 seconds to complete. In the browser, there would be a single XHR request issued that would take 400 seconds before a response was received.

Boxcar'ing in Lightning Actions

If you are building an application that uses polling or timers, you should wrap any code that modifies a component outside the normal rerendering lifecycle in $A.getCallback(). This will ensure that the framework will rerender the modified component and processes any enqueued actions right away. Not taking this approach can cause actions to be queued up indefinitely until a callback is requested through a different process (for example, a user returns to their desk and performs some other action in the system), which will send all of the queued up actions to the server simultaneously in transactions that have very high numbers of boxcars.

Visualforce JavaScript Remoting (Legacy)

Note: Visualforce is no longer the preferred method for building custom UX components in Salesforce, as the Lightning Framework (described in the previous section) offers greater flexibility. However, you may still encounter Visualforce pages in existing implementations.

JavaScript remoting is a tool that front-end developers can use to make an Ajax request from a Visualforce page directly to an Apex controller. JavaScript remoting allows you to run asynchronous actions by decoupling the page from the controller and performing tasks on the page without having to reload the entire page. This helps alleviate view state issues while still executing in the context of the user viewing the page. JavaScript remoting also allows you to ensure that you’re passing only the data that you need each time that you make a call.

Considerations for JavaScript Remoting

• While JavaScript remoting is asynchronous with respect to the Visualforce page, there are limitations to be aware of when using it. First, although asynchronous to the page, all JavaScript remoting requests are enforced by synchronous Apex governor limits on the Salesforce Platform, most importantly:
  • Synchronous Apex CPU Limit - default enforced at 15 seconds
  • Synchronous SOQL Limit - default 100 SOQL per transaction
  • Synchronous DML Limit - same for both synchronous and asynchronous actions (150 statements, 10,000 rows)
  • Synchronous Apex heap limit - 6MB
  • JavaScript remote requests are limited to a maximum of 120 seconds before being terminated
• In addition to the core platform governor limits, it is also important to note that most browsers only support six simultaneous requests. This means that once six Visualforce remote requests are in flight, additional requests will become queued within the browser and will not execute until one or more of the in-flight requests have been completed.
• It is not uncommon for our support teams to report seeing excessive polling of Salesforce from Visualforce pages that are performing activities such as checking case queue status or refreshing page data. This is usually a sign that the polling interval in the apex:ActionPoller component is set too low. Low polling intervals coupled with large numbers of end users can result in DB throttling due to excessive numbers of simultaneous threads holding database connections.
• Failure to clear timer intervals in JavaScript can cause them to accumulate, which will result in large numbers of JavaScript remoting requests executing even for a single user. As with excessive polling, this can result in database throttling due to connection pool exhaustion.

Boxcar’ing in JavaScript Remoting

Multiple JavaScript remoting requests can be issued at the same time by boxcar’ing them in a single HTTP request to the Salesforce core platform. On the platform, each of the boxcars (i.e. a separate JavaScript remoting action) will be processed serially and in order in a separate Apex synchronous transaction context. For example, if 10 remoting actions were boxcar’ed together and each took four seconds to run, 10 separate Apex transactions would be executed on the Salesforce Platform under the same request, taking a total of 40 seconds to complete. There would be a single request issued in the browser that would take 40 seconds before a response was received.

Boxcar'ing in JavaScript Remoting

Data Visualizations

Salesforce Dashboards

Unlike reports that run directly via the UI or API, dashboard-based reports actually execute asynchronously and are subject to both fair usage and flow control limitations, just like the asynchronous Apex message types. Dashboard-executed reports map into four separate asynchronous message queues for the reports: SMALL, MEDIUM, LARGE, and UNKNOWN. When a dashboard is refreshed, the reports underlying the dashboard panels are submitted to the various dashboard message queues. As the reports complete execution, the various dashboard panels will render in the UI.

Considerations for Dashboards

Reports used for dashboards should follow all report performance best practices. If any of the reports that a dashboard executes time out during execution, the dashboard status will remain as stale. When a user lands on a stale dashboard, the reports are automatically resubmitted to the message queues to execute. This can lead to message queue thread starvation of other message types due to overwhelming volumes of dashboard report message types.

CRM Analytics

There are four scenarios where asynchronous processing occurs within CRM Analytics:

• Dataflows make data from Salesforce and other systems available to dashboards in CRM Analytics.
• Remote Analytics allow you to combine data from multiple Salesforce orgs into a single CRM Analytics dashboard.
• Mass Updates allow you to update Salesforce records en masse directly from a CRM Analytics Dashboard.
• Writebacks allow you to load data from external systems into dashboards and then copy it to Salesforce.

Considerations for CRM Analytics

All of the processes mentioned above utilize the Bulk API in the background, but it's important to note that instead of being subject to Bulk API’s limits, they are subject to CRM Analytics Limits. Keep these limits in mind when working with large data volumes in CRMA.

Monitoring Asynchronous Processing

Because asynchronous processing happens in the background, any failures that may occur are typically not reported in the UI and thus may go unnoticed. Additionally, while rare, the platform’s flow control mechanism or fair usage algorithm may determine that asynchronous jobs need to be put on hold to ensure platform stability. This can create scenarios where synchronous processes attempt to perform CRUD operations on records that should already have been updated by asynchronous processes that haven’t run yet.

Issues like these make monitoring and alerting for asynchronous processes critical. Monitoring and alerting enables you to detect issues quickly and either fix them on your own or reach out to Salesforce for assistance. They represent a cost-effective failure mitigation or risk management strategy that will help to ensure that your asynchronous processes remain highly available.

You may have seen guidance on third-party sites for designing custom monitoring and alerting solutions that involve creating error logs when Apex code is executed and inserting the logs into a custom object or a big object. We don’t recommend this approach for the following reasons:

• This type of error logging only works when code is executed, not when code is NOT executed, which limits what you can actually monitor. For example, if an unexpected failure causes process execution to stop before the error logging is completed, then the log entry will not get created, and teams relying on the log for monitoring will not know what happened.
• Error logs stored in custom objects can consume data storage quickly and lead to large data volume issues.
• The act of writing logs into records consumes database connections and CPU processing time, which isn’t ideal in high-volume usage scenarios where server resource utilization should be kept to a minimum.

Take some time to explore all available monitoring and debugging options on the platform before opting to use custom error logging as your primary monitoring and alerting solution. Below are two alternative approaches.

Custom Query of the AsyncApexJob Object

If you want to build your own monitoring and alerting solution, you can write SOQL queries against the AsyncApexJob object to check the status of:

• Any batch Apex job
• Any method with the Future annotation
• Any job that implements the Queueable or Schedulable interface

With this approach, you can design a UI component that allows users to execute a query and view the results on demand, or you can build a background job that executes the query periodically and sends alerts if it detects any anomalies.

Asynchronous Apex Monitoring via Custom Query

Here are some considerations to keep in mind with this approach:

• While you can build a scheduled Apex job that repeatedly runs a query to monitor your asynchronous processes, the job itself will run asynchronously and will be subject to the same issues as other asynchronous process. A better solution is to design an external process that calls an API in Salesforce to run the query. With this approach, the query will run synchronously instead of asynchronously.
• Make sure to include a specific time frame and set of statuses and types of AsyncApexJob in your query. This will limit the number of records that get returned and improve performance. Also, make sure to test your query’s performance in a Full sandbox prior to moving it into production.
• Avoid executing your query more than once every five minutes, as it will consume database processing resources and could interfere with other processes if it runs too frequently.

Proactive Monitoring

Proactive Monitoring allows you to receive performance and dequeue latency alerts that get triggered during the execution of asynchronous processes. System administrators can elect to receive notifications via email, review past alert trends in self-service portal on Salesforce Help, and in specific critical scenarios, alerts may also automatically create Salesforce support cases, which will greatly reduce our support team’s time to detect (TTD) and time to engage (TTE). Note, however, that this feature requires a Signature Success Plan.

Closing Remarks

Keep this guide in mind and refer to it when building or considering asynchronous processing on the core Salesforce Platform. It’s always a good idea to understand the full scope of options available to you, and how they may fit with your specific use case. Be sure to thoroughly assess your current landscape before making changes to any of your existing architectures, especially if your current solution is working well.

Tell us what you think

Help us make sure we're publishing what is most relevant to you: take our survey to provide feedback on this content and tell us what you’d like to see next.