Reference - scheduled task properties

Run task on

Determines whether the task is executed by the Xperience administration application or the live site web application.

Most default tasks are intended to be processed by the administration application, as they manage data in the shared database. Executing tasks via the administration has the advantage that any performance requirements are offloaded from the live site application. Running on the live site is only recommended for tasks that work with the application memory or the local file system.

For more information, see: Processing scheduled tasks on the live site

Note: Only available for site-specific scheduled tasks. Global tasks are always processed by the administration application.

Task display name

Sets a name for the task that appears in the administration interface.

Task name

Serves as a unique identifier for the scheduled task, for example in the API. You can leave the (automatic) option to have the system generate an appropriate code name based on the display name.

Task provider

Selects the class that implements the scheduled task.

• Assembly name – specifies the name of the assembly where the task is implemented.
• Class – specifies the exact class (including any namespaces) that defines the functionality of the scheduled task.

The class must be available in the application where you run the task (live site, administration or both).

Period
Start time
Every
Between
Days

This group of properties sets the time interval between the executions of the task.

Notes:

• The interval settings do not ensure that the system executes the task at the exact time, only that the task is considered ready for execution. The exact run time depends on the global scheduling settings. See also: Configuring scheduled task execution
• The actual execution time and run duration do not affect the scheduling of the next run time. The system calculates the next run time based on the time for which the last run was originally scheduled (or the start time).
• If a task is still being processed when the next scheduled run time occurs (for example with long-running tasks that have a short execution interval), the task skips the given run and waits until the next run time.

Task data

Additional data provided to the task’s class. You can access the field from the code of the task, and use the value as a parameter. The Task data allows you to modify the task’s functionality without having to edit the code implementation.

Task condition

Allows you to enter an additional macro condition that must be fulfilled in order for the scheduler to execute the task.

You can write any condition according to your specific requirements. For details about available macro options and syntax, refer to Macro syntax.

Task enabled

Indicates if the system executes the task.

Delete task after last run

Indicates if the system deletes the task after its final run (applicable if the task is set to run only once).

Run task in separate thread

Indicates if the scheduler executes the task in a separate thread to improve application performance.

It is not possible to access context data (information about the current page, user, etc.) in the code of tasks that are executed in a separate thread.

Use external service

If enabled, the task is processed by the Scheduler Windows service. If the Use external service setting in Settings -> System is disabled, even tasks with this option enabled are processed by the Xperience application (live site or administration).

Only some of the default scheduled tasks support this option. The tasks that do not have the option available in the editing interfaces must be processed by the Xperience application.

If you wish to use the external service to run a custom task, the class must be defined in a separate assembly (you cannot add the task into the CMSApp administration project).

Run individually for each site

Only available for global tasks. If enabled, the scheduler executes the task repeatedly as a site‑specific task, once for each running site in the system. The task automatically runs within the context of the corresponding site.

This can be useful if you wish to manage a task in a single location instead of creating a separate one for every site.

Server name

Specifies the name of a specific web farm server where the task is executed. If empty, the task is processed by the first web farm server that runs its scheduler when the task is ready to run.

Use context of user

If the scheduled task needs to access data from the user context in its code (for example to check permissions), you can use this property to choose which user is provided. The scheduler always executes the task within the context of the selected user.

In most cases, the user context does not affect the functionality of the task and you can leave the (default) option. The (default) option means either the context of a public user, or the user from the context of the request during which the system executed the task (when using the request-based scheduler mode).

Executions

Shows how many times the task has been executed. You can reset this counter back to 0 by clicking Reset.