Find your content:

Search form

You are here

Use JSON serialization to get around parameter limitations for future methods?


Future methods can only take primitives or collections of primitives as parameters. To get around this you could serialize Sobjects (or classes) to a string and then deserialize them in the future method. Ex:

public static void test(string foo)
    Contact con = json.deserialize(foo);


This seems to work but I'm wondering if anyone knows of any drawbacks or pitfalls to this approach?

Attribution to: Greg Grinberg

Possible Suggestion/Solution #1

If you have a method that you want to run asynchronously and pass non-primitive arguments, one other option that became available in the Winter ’15 release is the Queueable Interface.

Attribution to: martin

Possible Suggestion/Solution #2

A few thoughts:

  • If you are dealing with a collection the string resulting from JSON serialization could become prohibitively large. This could result in heap size limit issues during deserialization.
  • The data in the sObject may be stale by the time the future method executes. Fields may have been changed on the Contact before the future method runs.
  • You may be serializing and passing data that you otherwise don't care about. E.g. You probably wouldn't want to serialize a blob data field.

Weather any of these are an issue or not will entirely depend on your usage.

Attribution to: Daniel Ballinger

Possible Suggestion/Solution #3

I've actually utilized this pattern to @futurize restful api callouts. In my case they objects were sObjects, but sobjects I wasn't worried about changing on me. As a design pattern, it works fairly well, even with moderately sized objects.

However, Daniel brings up the single most salient point, and one that needs to be re-iterated. If you choose to implement this pattern, you must start adding heap-stress-tests cases! I like to set my own heap "limits" and assert that Limits.getHeapSize() is below my own limit. This lets me isolate the heapsize used by json de/serialization of exemplar objects. That way I have some idea what my heapsize budget is for the rest of the @future call.

Attribution to: Kevin P
This content is remixed from stackoverflow or stackexchange. Please visit

My Block Status

My Block Content