Concept: Workday Scheduled Processes

You can access the

Process Monitor

report to view all types of background processes that are running or ran in the past. To view report and integration audit files, select the

Output Files

tab.

A running process doesn't stop other processes from running. Example: The Process Monitor displays that a manually launched EIB ran for 2 hours. At the same time, the Process Monitor can also display that other scheduled jobs launched between the start and stop time for the manual process.

When multiple processes run at the same time, they tend to slow each other down as they compete for the same resources. Example: A computer with 1 CPU can run multiple processes that display as running at the same time; the processes share 1 CPU.

A schedule expires after it reaches its final run date and completes the final run. You can’t schedule a process to run more than 5 times after the end of the next calendar year. Example: If you configure a monthly-scheduled process starting in 2019, the final occurrence is in May, 2021.

When a schedule reaches its second-to-last and last occurrences, Workday notifies the owner so they can extend the schedule. You can extend a schedule from the Related Actions of the process. You can extend multiple schedules at once by accessing the

Mass Update Scheduled Future Processes

task.

When configuring a schedule, the

Dependent

Run Frequency

enables you to configure a scheduled process that runs when an existing process completes, fails, aborts, or skips. You can chain multiple dependent processes and select a time delay between dependent processes to ensure that they run smoothly.

Workday processes scheduled jobs at the same priority as online user interface and web service transactions.

The Process Monitor doesn't visually distinguish between these types of processes:

Update processes (processes that change data in Workday).
Read processes (processes that don't change data in Workday).

The Process Monitor provides the status of the job based on its type.

Workday doesn't delay the initiation of scheduled processes when Workday is under high load from online user interface or web service transactions. Workday assigns the same priority to:

Scheduled processes.
User interface transactions.
Web service transactions.

Integration processing normally involves sending online web service requests to Workday. It's therefore possible for running integrations to produce high online load on Workday.

Workday provides a best-effort attempt to initiate the process at the scheduled initiation time and processes it as quickly as resources are available. However, processes run on shared resources, and Workday doesn't guarantee when a job initiates and when the job completes. These factors depend on the current load on Workday and the work included in the scheduled process.

Daily, weekly, and monthly schedules use the time and calendar from the local time zone settings for the tenant. Example: For jobs scheduled to start on Saturday at 02:00:00, Workday initiates them when the tenant day is Saturday and time is 02:00:00. Workday initiates jobs at the specified time regardless if it’s Daylight Savings Time or Pacific Standard Time.

You can configure a scheduled process to not run on a holiday, or to run before or after the holiday. You can connect a scheduled process to a holiday calendar (defined by you). The scheduled process can then run before or after a holiday, or reschedule to a weekday.

An example of a time change is when clocks shift from Pacific Standard Time to Pacific Daylight Time. Not all geolocations experience a time change, and the days these changes occur can vary by country.

If a schedule fires at most once on a given day, after a time change it continues to fire at the specified time. (Workday attempts to honor the start time, however, there can be slight delays depending on tenant load). If you have a schedule that fires every Monday at 8AM local time, the schedule fires at 8AM. The schedule time doesn't change after the time change because the cadence is daily, and the unit of measurement is a day.

If a schedule fires multiple times per day, after the time change, the schedule continues to honor the time between scheduled events. If you set a schedule to fire every hour, or every 2 hours, the schedule continues to fire according to that time interval. The time interval doesn't change, regardless of how the time change might impact the interval.

When the time changes, it might appear that a schedule start time has changed. However, the schedule is honoring the configured time between events that you've configured. Example: You configure a schedule to run once every hour. At the time change, 1:59:59AM ticks over to 1:00:00AM. In this instance, the schedule would fire as follows:

In this instance, Workday displays 2 fire events at 1:00AM. However, the schedule has continued to fire every hour.

This schedule example shows a schedule that fires every 2 hours:

In this example, the schedule continues to honor the requirement that it fire every 2 hours. The same behavior in these examples holds true if the time were to move forward, rather than back. The scheduler would honor the

defined time interval.

In summary, the scheduler attempts to honor the time interval set on the schedule. If you set a schedule to fire every X hours, it attempts to do so, regardless of how the time change might alter the exact times when those evaluations occur.