Question
Queueable Apex: Transitioning from Future Methods for Complex Data Types
Nia Byte
0 reputation · 25 May 2022, 21:01 UTC
89.2K views1
Loading…
0 reputation · 25 May 2022, 21:01 UTC
Salesforce developers often transition from @future methods to the Queueable interface to leverage job chaining and the ability to pass complex data types, such as custom Apex objects or collections, which are not supported by future methods.
While Queueable provides higher flexibility, the non-deterministic execution order of asynchronous jobs introduces uncertainty when multiple jobs must interact with the same set of records. Ensuring a specific sequence of operations requires a chaining strategy, but this introduces constraints regarding the maximum number of chained jobs allowed in a single transaction.
LimitException during high-volume data processing.What is the recommended pattern for sequencing multiple Queueable jobs to ensure a strict execution order without hitting chaining limits? How does the platform handle the transaction boundary when a chained job fails?
34775 reputation · 25 May 2022, 23:54 UTC
To guarantee a strict execution order while staying within the 50‑job chaining limit, chain the next Queueable inside the finish method of the current job.
Each Queueable executes in its own database transaction. If a chained job throws an exception or encounters a DML error, the platform rolls back only that job’s transaction and halts the chain; no further jobs are invoked. Therefore, design the logic to be idempotent or confine critical data updates to a single transaction that spans the entire chain.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 25 May 2022, 23:32 UTC
One clarification: a stateful Queueable that re-enqueues itself does not reset the chain-depth counter. The commonly documented ceiling is 50 queued jobs from one root, but confirm the current org limit in Setup rather than hard-coding it. For work exceeding that ceiling, use a control record plus Scheduled Apex to launch a new root only after the prior batch writes a completion marker; make that transition idempotent so a repeated launch cannot overlap work.
Chaining guarantees that the next job executes after its predecessor finishes, not that it starts at a predictable time. Each job commits independently, so a later failure does not undo earlier updates and stops subsequent links. Make each step idempotent and reconcile incomplete control records. In a sandbox, inspect AsyncApexJob and its ParentJobId to verify linkage and failure behavior.
salesforce
apex