I am looking to find a best practice/framework to implement a schedulable batch.

I don't know if create an Apex Class that implements Schedulable and Batchable interfaces is the correct way or create two different classes for each interface are enough (Single Responsibility Principle).

Do you have any suggestion about this topic? Thanks!

2 Answers 2


While you can implement both Database.Batchable and Schedulable interfaces in same class but a better approach here is to separate the "responsibility" of the classes based on what they are supposed to perform.

By its definition, a Batch Apex helps you to deal with long running processes or deal with very large data volume which you cannot perform in synchronous operations.

A developer can now employ batch Apex to build complex, long-running processes that run on thousands of records on the Lightning Platform.

And that, you can schedule a batch class to be executed at a particular time. Apex Scheduler not only can schedule a batch class, but it can also help you to invoke any other apex class at a particular time interval.

To invoke Apex classes to run at specific times, first implement the Schedulable interface for the class, then specify the schedule using either the Schedule Apex page in the Salesforce user interface, or the System.schedule method.

I usually prefer to keep the "batch logic" and the "scheduler logic" in two different classes. That way I always know that I have written a particular scheduler for a specific purpose. With this separation, I have more control in my scheduler if at all I want to say invoke any other operation once my batch has executed successfully. If I kept it in a single class, that would lead me to handle multiple things in the same class and making it difficult for any debugging in future.


I think the "correct" way is subjective. Like in Jayant Das' posted answer, by separating the responsibility of the class gives the impression of having more control over the process, the takeaway is that both are really comparably indifferent along the lines of having control of the process.

I have used both ways mentioned to handle this process. I believe, also subjective, that if all your scheduler is doing is calling a batch process, then you should include the schedule constructor and execute methods within the same class. The context passed into these execute methods is enough for the system to know what to execute. Bear in mind that if both are parameterless constructors, this will not work well for you and you should put them in two separate classes. If your batch and schedule constructors are different, this approach would be the way to go.

If in your schedule controller that you are doing some pre-processing that would make the code harder to read BEFORE passing records to your batch, then you should keep them separate for purposes of maintenance. This approach will be best if you use parameterless constructors in your batch and schedule processes.

I am not sure if there is a "Best Practices" approach on that, but I think that that your decision should come down to how much work it will take for maintenance long term, and how you plan to construct your instance (as noted above).

In my experience, that has been how I have made that decision.

You must log in to answer this question.

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