Skip to content

Background Why Do We Want This?

Jump to bottom
Bob Hatcher edited this page Mar 10, 2021 · 1 revision

This started when I had a simple question - Salesforce code wants to be synchronous, but why? Why can't we keep what should be synchronous synchronous, but allow for asynchronous processing when possible? That's what Queueables are for.

Turns out that's easier said than done. What I was looking to do was to implement a pattern where you have:

  • Trigger calls trigger handler
  • Trigger handler does its thing, but "peels off" an asynchronous process for non-time sensitive processing

The problem is that in test code, you can't chain Queueables which really kneecaps this really cool capability. In attempting to understand this I took to StackExchange, where this was explained in great detail by sfdcfox, who also provided a QueueableUtilities class that would handle whether to attempt to spawn a Queueable or not.

This project initially started as a demonstration of how I used this StackExchange answer to implement queueables practically in my org. More recently I have expanded on it to make it simpler and cleaner.

Clone this wiki locally