A number of approaches to more reliable scheduling and continuous processing have been used over time on the Salesforce platform, all of them suffering from serious drawbacks. These include:

  • suicidal scheduling, where a scheduled job enqueues another scheduled job and then aborts itself. Salesforce has been threatening to penalise the approach with no less than 5 minute delay. Job execution is not reliable.
  • chained queueables, where a queuable calls itself. Salesforce states that the back-off for that will top at around a minute. Job execution is also not reliable. Hard to test in developer orgs.
  • chained batch jobs, where a batch job calls itself. The newer BatchApexErrorEvent also offers a way to handle limit exceptions. Salesforce has a back-off for this job type as well, topping at around 4 minutes. Again, job execution is not reliable.
  • virtual batches, where a custom iterable class essentially produces a range of numbers, and actual work and querying is done inside batch scopes. Shares similar problems with other job-based approaches.
  • Javascript driven execution, where @RemoteAction methods are used from a browser to drive execution. Users have to keep their browser windows open.
  • API calls, where an external system is in charge of execution scheduling and calls in to Salesforce to perform work. While plentiful, API calls are limited and a number of platform users have started with this approach.

Are there any novel approaches that would allow precise scheduling and continuous execution with less drawbacks than the ones above?

  • I believe it's termed suicide scheduling, not suicidal scheduling.
    – Adrian Larson
    Nov 19, 2019 at 18:37
  • We run scheduled batches in AWS batch processors and push it back to salesforce.
    – RedDevil
    Nov 19, 2019 at 18:42
  • 1
    @AdrianLarson developer.salesforce.com/blogs/engineering/2014/10/… labels it suicidal but the name itself is not important
    – ipavlic
    Nov 19, 2019 at 19:33
  • 1
    ...anything async on SF platform is subject to resource availability and therefore not reliable or precise by any reasonable definition.
    – identigral
    Nov 19, 2019 at 19:33
  • @RedDevil this sounds like a subset of the API calls approach, where “work” is also done externally.
    – ipavlic
    Nov 19, 2019 at 19:39

2 Answers 2


For my SObjectWorkQueue I am using batch chaining and serialized work records. It’s not a new approach but worked very reliably in the past for me. Not sure if I ever saw this penalty.


  enter image description here


I would like to point Javascript driven execution:

Javascript driven execution, where @RemoteAction methods are used from a browser to drive execution. Users have to keep their browser windows open.

This is not the case anymore, with the growth of recent technology, you can run windowless browser via command line and write your scripts to run your VF page.

One option would be to use Headless-Chrome and Puppeteer, you can log in via JWT and open VF page and start your job. With the power of batch scripting, shell scripting you can automate this using cron jobs.

I have seen people use this for automated testing UI. Anywho, this can be used to achieve scheduled batch job runs.

This wont' consume API calls, and you decide your own running time as each transaction would be synchronous.

  • note that this costs a license if done properly. Nov 21, 2019 at 20:17
  • @CharlesKoppelman yes it does, but eventually the costs saved in api calls and using a proper Middleware is lot more than a single user licence cost Nov 21, 2019 at 20:32

You must log in to answer this question.

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