From Salesforce documentation: "The System.schedule method starts an asynchronous process."


This is demonstrated in the fact that org-wide async limits include schedulable, in addition to future, queueable, and batch. (also in the above documentation)

Why then do scheduled apex processes abide by the normal synchronous governor limits, e.g. maximum CPU time = 10 seconds? This seems to clearly be the case based on my debug logs.

Any help in clarifying this dual-identity is greatly appreciated.

Thanks! Brent

  • 2
    Just because you run code async does not give you free reign to take up all the resources. Batch apex has some relaxed limits on rows if you use a query locator but you still have a rule book to follow with any code
    – Eric
    Jul 16 '16 at 3:39
  • Eric, thank you for taking the time to respond, but that doesn't answer my question - I'm wondering why the rule book for this process is different than that of other async processes. Salesforce documentation states that the CPU time limit for async processes is 60 seconds (in addition to other relaxed limits with async): developer.salesforce.com/docs/atlas.en-us.apexcode.meta/… So why is this not true for this one? Jul 16 '16 at 20:07

You can implement schedulable interface with batchable interface. When you do, then you get the higher limits. Without the batchable interface, you're not really using the asynchronous processes that are especially beneficial to the platform where the code runs in batches using a query pointers.


If you want to increase CPU time limit within the execute() method call future method.

global void execute(Database.BatchableContext bc,List<SObject> sObList){

@future(limits='2xCPU') or @future(limits='3xCPU')
public callfutureMethod() {
//your code

Ref :https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_enhanced_future_overview.htm

  • This is a pilot feature and is not generally available.I think you should also add this statement .
    – Mr.Frodo
    Jul 16 '16 at 5:53
  • Thanks for your post, but sadly this does not meet my needs. I am operating my logic on batch inserts of thousands of records, and each sub-batch of 200 will need to lock related records for update, and therefore need to run in a smooth, timely, sequential manner. I should also state that I am very aware of the details of future, queueable, batch, etc. I have found a solution for my code through calling a queueable method from a scheduled method, but at this point am only wondering why the queueable part is even necessary, i.e. why doesn't the scheduled async process carry async limits? Jul 16 '16 at 20:13
  • Brent crmprgdev has given proper explanation about why Salesforce has done in this way. Jul 17 '16 at 17:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.