Server Administration > Automate Tasks and Calculate Data Using Event Triggers > Creating Workflow and Document Event Triggers > Creating Scheduled Triggers
 
Creating Scheduled Triggers
Scheduled triggers run on a specified schedule against all items matching the specified query. Any modifications appear as if the user selected in the Run As list made them.
The general steps required to create a scheduled event trigger are as follows:
1. Select the schedule trigger type, and assign a user to be recorded as performing the script the trigger runs.
2. Provide a description for the trigger.
3. Specify the schedule the trigger runs on.
4. Select an existing query to specify which items the query runs on.
* 
Because scheduled triggers are based on queries, triggers are subject to visibility rules. Visibility rules restrict access to specific information based on project or item type.
5. Select a script file from the library for the trigger to run, and fill out the parameters for it.
* 
Scripts listed under the samples directory (for example, samples/breakLockNotification.js) are for configuration management and are not applicable to workflow and document management.
Backlashes (\) in parameters are truncated after you save and run the trigger, for example, in a directory path. To avoid this, use forward slashes (/).
6. Assign the values to the fields the trigger modifies when it is run (if the trigger is one that modifies field values in the database).
Key Considerations
All triggers run sequentially. This prevents an increase in the use of server resources each time a new trigger is added.
Scheduled event triggers are evaluated on the Integrity Lifecycle Manager server’s time zone.
Schedules are recomputed after any given run, at system startup, and when the triggers are changed. If a set of triggers takes longer to run than the next scheduled trigger is set to run at, the next schedule run of the trigger is missed.
All modified items from a single scheduled trigger are part of one single transaction. If the trigger fails, no items are modified. Unlike rule-based triggers, since each trigger operates independently of its own batch of items, each trigger commits the change to the database independently.
When the server is shut down or the service is stopped, the server does not reschedule triggers that were not able to run to during that time.
To create a scheduled event trigger in the GUI