I am new to Salesforce and hence a lot of silly questions. What is the rational behind defining future methods as Static? I mean has these methods been not static what harm would have they caused?

  • Future method by definition is static so that variables with this method is associated to the class and not the instance and you can access them without instantiating the class. This is something defined as a rule by Salesforce. Jun 15, 2015 at 3:24

2 Answers 2


Future methods are "light" batch classes. Basically, salesforce.com took a look at everything "wrong" with batches, and stripped them out to provide a lean, mean interface for asynchronous calls. They have to be static because the underlying system is optimized to work as efficiently as possible.

Batches need at least three asynchronous cycles to do everything: start, execute, and finish. At each step, the object graph has to be deserialized before the function can be called, and this leads to longer initialization times. Even worse, if you use Database.Stateful, you'll also incur extra serialization at the end of each function call, taking up more execution time. It's simply more wasteful of system resources than it could be.

Future methods are the exact opposite of batches, designed to be simple. They don't serialize object graphs (only primitives and collections of primitives are allowed), they don't return a Job ID, and they use only one execution cycle instead of three. As such, since they don't store object graphs, there's no way a future method could be anything other than static. There's simply nowhere to put the data. It is meant to be a lightweight asynchronous interface that wouldn't bog down the system's resources as much.

For example, that's why you're allowed 50 future methods per transaction, while batches can only be filled up 100 system-wide calls at any given time (with flex queue, which leaves up to 95 "on hold"). Because they're so much smaller, you can call a great many more of them than you can batches in the same amount of time. If there was no requirement to have them be static, this would increase execution time and harm performance.


A @future (being async) doesn't have access to the original instance of the class, as that is removed from memory when the processing context has finished. What this means is that you can't have a non static function for the sole reason that the instance of the class no longer exists.

For example:

public class TestClass {
    public static void staticFunction() {

    public void nonStaticFunction() {

//This won't work:
TestClass.nonStaticfunction(); //object TestClass doesn't exist

//These will:
TestClass.staticFunction();    //static, so it doesn't need an instance of the class

TestClass tc = new TestClass();
tc.nonStaticFunction();        //have an object now, so it will work

Future call doesn't create an instance of an object, so it can only access static functions.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .