This is a seemingly simple question but the recommendation will depend on how the model is configured. Note that batching isn't really considered as a solution here since that could also be a requirement that is superimposed over the shift or control logic as another layer of complexity.
Operators transporting and processing
If you have operators in your model that are transporting from the queue to the processor and then working on the item in the processor, then by just putting the operator on a timetable, you will be preventing transport jobs from queue to the processor and the items will accumulate.
No operators - processor on a timetable
Without operators if you have the processor on a timetable you can close/stop the input of the processor when the shift ends to prevent more items entering and reopen/resume the input when the next shift starts.
No Operators - queue on a timetable
As above but instead of opening and closing (or stopping/resuming) inputs you'd open and close (stop/resume) the queue's outputs.
The references to the stop/resume vs open/close are there in case you need to mange the ports for some other control logic, beside the timetable/shifts. The difference is that while open/close are absolutes in that they always open or close the port, the stop/resume actions stack allowing you to stop for some control aspect(s) and then additionally stop for the end of shift. Then when the control part resumes the port, the timetable stop is still in effect and the port will not be open for transfer until that and any other stop on the in/output is also resumed.
