Asynchronous Processing in Apex On Salesforce: Part 1 – Future Methods

Asynchronous processing applies to any situation in which we don’t want to block the user or current transaction while a separate/remote request is being processed. 

Salesforce provides various options for running custom Apex code asynchronously. Future methods, queueable apex, scheduled apex and batch apex are a few ways in which the Salesforce platform enables asynchronous processing. We’re releasing a series of posts covering each of these ways in detail which you can use for asynchronous processing. 

In this first part, we will look at the Future Method. It is the simplest option for asynchronous processing. A future method runs in the background, asynchronously. It can be called to process an independent operation in its own thread, on its own time.

Let’s review some important information about future methods and the situations where using a future method is most appropriate.

Key Considerations For Using Future Methods For Asynchronous Processing On Salesforce

Simplicity: Using a future method is very simple. Just annotating a method with @future annotation makes it a future method. The method must be static and must return void. Also, the parameters have to be primitive data types. Objects and Object Lists are not allowed as parameters.

Higher Governor Limits: Future methods have higher asynchronous governor limits. E.g. a future method transaction can execute 200 SOQL queries, double that of a synchronous transaction. Maximum allowed CPU time and total heap size are also significantly higher, allowing you to perform more complex processing.

Multiple Future Invocations: You can have up to 50 future method invocations in one transaction. So multiple asynchronous future method transactions, doing independent operations, can be invoked from the main transaction. This is useful if you need to make multiple independent API calls.

Cannot Return Information to Main Transactions: Since future methods return void, results from a future method are not available immediately in the main transaction. Your main transaction shouldn’t depend on some operation performed by the future method. The future method will execute independently and should perform independent tasks. Don’t use it when you need to use the results from the asynchronous operation in the main transaction. Also, any error handling and notification should be handled by the future method separately from the main transaction.

No Additional Asynchronous Processing: A future method can’t invoke another future method. Also, a future method cannot be called from a batch apex. So you can’t chain one future method call to another.

Cannot be Scheduled: A future method executes as soon as resources are available. So you can’t schedule it to execute at a specific time. If you need execution at a specific time then you should use Apex Scheduler.

No Monitoring: A future method doesn’t have a job ID. So you cannot monitor a specific future method execution. You can query the AsyncApexJob object to query the status of future methods. But you will get the status of all future method invocations of a specific class/method. Since you don’t get a job ID back, your application can’t track the status of a specific future method invocation. 

Cannot Control Sequence of Execution: A future method executes when the system resources become available. If a main transaction triggers multiple future methods, there is no guarantee on the sequence of execution of all the future method invocations. Also, multiple future methods could also execute simultaneously. So you should avoid situations where one future method locks records needed by another method to update. Each future method should perform an operation independent of the other method.

When to Use/Not Use To Future Methods

API Callouts: The most common use case for future methods is API callouts that take a long to complete. The future method of doing the API callout will then also need to take care of recording the status in some way so that your application knows the details of the request. Since the future method doesn’t return anything, you can’t return the status to the main transaction. Instead, the future method itself should take care of storing the API response details as per requirement. Any email notifications etc. can also be then sent to inform of the status details. Note that any DML operation to store status needs to happen after the API call. You can’t perform a DML operation before an API callout.

Mixed DML Operations: Another common use case for future methods is when the operation involves mixed DML operations. In Salesforce, DML operations on setup sObjects (e.g. User), can’t be mixed with DML on other sObjects in the same transaction. E.g. Your requirement to update a custom field on User after another field is updated on a Contact, will result in a mixed DML operation. Hence it will not be allowed. In such a case, you can separate the setup object transaction in a separate future method call-out.

Complex Independent Operation: Since a future method transaction has higher governor limits, it can be used to offload complex processing. Any operation requiring higher SOQL queries or complex processing can be performed in a future method.

Do Not Use for Processing Large Number of Records: While a future method has a higher governor limit and can independently process separate transactions, it should not be used to process a large number of records. A better approach would be to use batch apex. This is more efficient than creating a future request for each record.

Even millions of records can be processed using batch apex. A future method should be your choice for independent transactions such as API calls, complex operations or mixed DML operations, but not for a large number of records processing.

Wrapping It Up 

In summary, use a future method when you want to execute a simple, independent, transaction asynchronously. The most common use cases are a) making an API call, b) performing operations on setup objects as part of a trigger/apex or c) performing an independent yet complex operation as part of a main transaction. Stay tuned for part 2 of this series where we will review a few other ways of executing operations asynchronously in Salesforce.