If you need to start a Process within a specific schedule you can use a Schedule Trigger to define a schedule which will then start that Process within the scheduled times. Schedules can be configured to start in specific intervals within set time and date ranges or to execute once at given dates and times.

Please note that Processes are scheduled with only best effort guarantees: the Process will be started if the schedule is open when the scheduling database is polled. Because the poll delay is one second by default, this can mean that the actual execution of a Process may start 1-2 seconds later than the actual scheduled time. Therefore you should not create too short time windows or expect the Processes will start at exactly the given time.

Once a Process has been launched, it will be allowed to start and execute. This means that if you launch a Process with a large number of tasks, the execution of the Process Instance may take a long time, continuing even after the time window has ended. If this can be a problem, the Process executions should be scheduled more evenly in time.

When a scheduled Process is created, imported or activated, it will execute when the time window next opens. 

Any Process can contain multiple Schedule Triggers if you need to have different or overlapping schedules. To add multiple Schedule Triggers simple add a Start Element to the Process canvas and connect it to the first step of the Process. However, please note that each schedule is evaluated separately, so you may get more than one executions of a Process triggered at the same time.

You can limit a Process to run only one scheduled Instance at a time by setting the Run only one scheduled instance at a time option for the Trigger. For instance, if a Process is scheduled to execute every 10 minutes, but the Process Instance takes 13 minutes to complete, a new Process Instance will be scheduled only after previous Process Instance has finished, i.e. about 14 minutes from the start of the previous Instance. 

However, please note that if you start a Process manually e.g. with the "Run Once" action, the new Instance will be executed, even if the Run only one scheduled instance at a time setting was turned on and a previous Instance was already running. This is because the setting is only checked for scheduled Process Instances.

You can also set a schedule to be open only on specific days of week or month. For monthly schedules, you can also define it to be open e.g. on the first or last day (or weekday or e.g. Monday) of a month, based on the day ranks (Note that if you choose multiple days, they will all be counted, and weekday/weekend day options will override any specific days). Also, if you use the explicit days option to execute a Process e.g. on the 30th of each month, the day check is exact, so the schedule will not actually be open on February, with no 30th. 

For more complex scenarios, you can also give specific dates (e.g. bank holidays) when the schedule should or should not execute. To do this, just add the dates to the Chosen dates list and choose if the schedule should be open "Only on these dates" or "Never on these dates". You can also import the dates from a .ics file. Please note that the excluded dates will be evaluated separately from the other date limits, and after any season limits are checked. This means that if you e.g. have a schedule that runs on the first of every month, but exclude bank holidays, the Process will not run in January at all, as the 1st of January would be a bank holiday. Also, if you have defined a season end time, e.g. 2017-12-31, the Process will not run after it, even if you would have explicitly chosen a date after the season end, e.g. 2018-01-06.

The Process schedules are checked according to the given time zone, which also takes possible daylight saving time (DST) adjustments into account. This means that if you schedule a Process to run every day at 12:00, it will execute at that time, whether DST is in effect or not.

However, because the scheduler uses the adjusted time, the time periods when DST is starting or ending may cause Processes to be scheduled a bit differently than normally: In spring, when DST is starting, the clocks are turned forward, and one hour gets skipped. The opposite happens in autumn, when the clocks are turned back, and there is one additional hour. The effects of these adjustments for different schedules are shown in the tables below.

When the DST is starting, one hour (in EU, the hour from 3 to 4 AM) will be skipped, i.e. the clock will skip from 2:59:59 to 4:00:00. For Processes this means that the schedules cannot be open during this period. The schedule start and end times are adjusted as follows:

When the DST is ending, one hour will be added to the day, i.e. the clock will be turned back from 4:00 to 3:00. Therefore the local time will be 3:00 twice for that day. For Processes that start or stop at this ambiguous hour, the ambiguity is resolved by always choosing the first possible occurrence.

DST changes also affect repeating schedules. Because the repeats are calculated from the schedule's local start time, the repeats will start to adhere to the adjusted local time as soon as a new schedule is opened. 

If the schedule start time or end time is adjusted due to the DST change, a warning will be logged to the event log for every time the schedule is checked, i.e. every minute. If the schedule would be skipped, i.e. the schedule starts and stops during the invalid period (3:00-3:59:59), an error is logged.