Does the future method support all the data types as parameters or arguments?

No. A @future method accepts a strictly limited set of parameter types. Anything outside that list throws a compile-time error.

What’s allowed

• Primitives — Id, String, Integer, Long, Decimal, Double, Boolean, Date, Datetime, Time, Blob
• Collections of primitives — List<Id>, Set<String>, Map<String, Integer>, etc.
• Arrays of primitives — same idea (String[], Id[])

That’s the entire list.

What’s not allowed

If you try, the compiler rejects the method with: “Methods defined as future cannot have parameters of type sObject or that contain an sObject.”

Why the restriction exists

@future jobs run in a separate transaction, potentially minutes or hours later. By the time the method executes, the sObject you passed could be stale — another user might have edited it, deleted it, or changed fields that affected sharing. Salesforce sidesteps the staleness problem by forcing you to pass Ids only, and re-query inside the future method for the latest values.

The standard workaround

Pass a List<Id>, then re-query:

public class AccountSyncer {
    @future(callout=true)
    public static void syncToErp(List<Id> accountIds) {
        List<Account> accounts = [
            SELECT Id, Name, Industry, AnnualRevenue
            FROM Account WHERE Id IN :accountIds
        ];
        // make callout with fresh data
    }
}

This guarantees fresh data and avoids the parameter restriction entirely.

Common interview follow-ups

• Can I pass a wrapper class with a few fields? — No. Only primitives and collections of primitives.
• Why does Queueable allow sObjects? — Queueable serializes the entire instance using standard Apex serialization, and it’s a newer API designed without the parameter constraints.
• What about JSON-serialized objects? — You can pass a String containing JSON and deserialize inside the future method. It’s a workaround, not pretty, but valid.

Verified against: Apex Developer Guide — Future Methods. Last reviewed 2026-05-17.