Schedules

Create and manage time-based service triggers for workflow automation.

Schedules are used to automate services and run them at set times. Common use cases are running batch and recurring jobs such as synchronizing data with an external system, polling for changes, and sending notifications.

When triggered, the schedule will send a request to the specified service endpoint. The result of the request (success or failure) is recorded in the schedule logs.

Usage

Any task that needs to be run on a regular schedule is a candidate for a schedule.

• Fetch data from an external API every 15 minutes to populate a dashboard.

• Synchronize customer data with your CRM nightly at 2am.

• Refresh an OAuth access token used for integrations every 3 hours.

• Send an email every morning with a summary of all orders from the previous day.

Important

• Ensure that the selected service account has permission to run the selected service and the necessary object class permissions. If you are updating a secret within the service, that permission must be granted.

• After you have enabled a service you will need to disable it to make changes. Don't forget to enable it again when you're done!

Properties

Property	Description
Name	A descriptive name. This is shown in the logs.
Description	A longer description of the schedule. It may be useful to specify what happens in the service being triggered and when the schedule runs.
Service	The service containing the endpoint the schedule will call.
Endpoint	The endpoint the schedule will call.
Service account	The service account that will be used to run the service.
Cron expression	The time schedule on which the service will be run in the form of a cron expression. The expression is validated and an error is shown if it is not valid.
Time Zone	The time zone used by the schedule when evaluating the cron expression.
Override Service Time Zone	If this is enabled, the time zone specified above will override the time zone specified on the service.
Restrict to Selected Environments	By default a schedule will run on all enabled environments in a solution that have the Enable Scheduler checkbox selected under Environments. You can restrict which environments the schedule will run on by selecting this checkbox and then selecting the environments where the schedule should be enabled.
Enabled	Activate the schedule. This must be checked for the schedule to run.

Cron expression

A cron expression typically consists of five values separated by spaces, in this order, within the stated ranges.

• Minute (0–59)

• Hour (0–23)

• Day of month (1–31)

• Month (1–12)

• Day of week (0–6, where 0 = Sunday)

The following example would be run every 3rd hour, on the hour: 0 */3 * * *.

Schedules also support second granularity (0–59). This can be added as the first value in the expression if required.

Available patterns

Symbol	Description	Example
*	any value	*
,	list of values	1,5,7
-	range of values	1-3
/	steps	*/2

Good to know

• Hover over the blue dot to see a written description of the current cron expression.

• Use crontab guru to help you generate a valid expression and to find common examples.

Behaviour of Schedules

Services may be run in parallel by default. 2-3 Services may execute at the same time, due to horizontal scaling in the infrastructure. Sometimes more depending on the subscription tier (configuration).

You should try to spread the load of the scheduled services when you have multiple schedules, and you should make sure a given schedule is not too frequent, always allowing the previous execution to finish before the next execution starts.

Here are a few notes on the built-in behaviour of Schedules:

• Two different Schedules may run in parallel. 2-3 parallel Schedules are normally supported, sometimes more. However, you should strive towards minimizing parallelism to spread the load.

• For a given Schedule: If the previous execution has not finished when the next execution starts, the next execution will be skipped.

  • Example: If a Schedule is set up to run every minute, but the execution lasts 2.5 minutes, only every third Schedule will execute.

• Given the above example: If the Service Endpoint has the setting Run Async, the Service will be executed every minute since Run Async reports back success immediately, and the execution just continues on the server. Use Run Async with care, and preferably in combination with No Concurrency.

• If a Service Endpoint has No Concurrency, any given schedule will fail if that Service Endpoint is being executed (triggered from a previous Schedule, or an external party or App) when the Schedule starts.

• If Services are exhausted (e.g. running on maximum capacity), a Schedule may fail. In this case, the Schedule may report Failed in the Logs, whereas the Service does not report anything (it did not have the possibility to even start, thus not reporting anything).