The following table explains the properties of scheduled tasks. To configure tasks:
- Open the Scheduled tasks application.
- Edit ( ) the task.
Task display name
Sets a name for the task that appears in the administration interface.
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.
Selects the class that implements the scheduled task.
This group of properties sets the time interval between the executions of the task.
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.
Allows you to enter an additionalthat 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 the Macro expressions chapter.
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 Installing the Scheduler Windows service instead of the web application. If the Use external service setting in Settings -> System is disabled, even tasks with this option enabled are processed by the application itself.
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 application itself.
You cannot define the task in the App_Code folder if you wish to use the external service. To run a custom task externally, you must add a new assembly to your project and then define the task class there.
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.
Sets the name of the web farm server where the task is executed. This field is applicable only if your application is running in a Web farm environment.
To add a new task for all web farm servers currently registered in the system, select the Create tasks for all web farm servers check box below the field.
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).
Shows how many times the task has been executed. You can reset this counter back to 0 by clicking Reset.
Was this page helpful?