Administration Guide : Trigger Set Configuration : How do Trigger Sets work?

How do Trigger Sets work?
There are four ways that the database will initiate Actions from a Trigger Set:
A Value Trigger runs Actions whenever a value change in the database meets the criteria set in the rule. For example, a user changes a Data Field value from No to OK using a pop-up menu and submits the change from a browser. After updating the database with the new information, Xinet will check the configured Trigger Sets to see if any are set to occur when the field value changes to OK or when the value changes from No. The change to that field is what will cause the Trigger Rules (if any qualify) to run their Actions.
A Date Trigger runs Actions when a certain time-based condition is met. For example, if a field named Due Date is set to 9:30, and there is a Date Trigger configured to run Actions when the time reaches one hour before the time in Due Date, then at 8:30 this trigger will run its Actions.
A File Event Trigger runs Actions upon changes to the file system which effect a file’s history. You can have the Xinet database tie any of the following file-system changes within the Active Path to fire a Trigger:
Aggregated Upload: For a batch upload of multiple files, triggers a single action (rather than an action for every item)
New File : A file previously unknown to the database arrives inside the Active Path
Delete: A file is deleted from within the Active Path
Download High Res : A high-resolution image is downloaded from the Active Path through Xinet
Download FP0: An FPO is downloaded from an Active Path through Xinet
Preview Viewed : A Xinet user previews a file within an Active Path
Upload : A user uploads a file to an Active Path on the Xinet server. If set up, this may also trigger a New File event.
Image Order : A user uses the Xinet Custom Image Order CGI on a file in the Active Path
Move Into : A user moves a file into a folder within an Active Path from a place in the file system that is not within that Active Path
Image Replacement : An image has been OPI-replaced in a print queue (including PDF/IR queues). Useful for accounting purposes when interested in tracking asset use, such as downloads, copies, and writes. That list now includes Image Replacement.
Portal Trigger: The portalDI setevent Action or the venturelog(8) -portaltrig flag has been invoked. Allows developers to program custom Triggers that do not require a metadata Field change.
An Annotation Event Trigger runs Actions upon changes to Annotations, including:
New Annotation: A Xinet Portal user adds an Annotation to a Xinet file preview.
Edit Annotation : A Xinet Portal user edits an Annotation in a Xinet file preview.
New Rectangle : A Xinet Portal user adds a Rectangle Annotation to a file Annotation preview.
New Sketch : A Xinet Portal user adds a new Annotation using the Sketch Annotation tool.
New Text Annotation : A Xinet Portal user adds a new Text Annotation to a file preview.
New Stamp : A Xinet Portal user adds a new Stamp Annotation to a file Annotation preview
Edit Rectangle: A Xinet Portal user edits an existing Rectangle Annotation. Annotation
Edit Sketch: A Xinet Portal user edits an existing Sketch Annotation. Annotation
Edit Text Annotation : A Xinet Portal user edits an existing Text Annotation.
Edit Stamp : A Xinet Portal user edits an existing Stamp Annotation. Annotation
The following presents some examples of File System Triggers:
  
Each type of trigger is useful in different scenarios. If you require immediate feedback about a change in the database, such as Approval Status, then a Value Trigger Rule is best for monitoring that change. If you want to have things occur at a certain time, such as 90 minutes before the file is due at the press, send it via FTP, then a Date Trigger Rule will be appropriate. If you want a change within the file system to initiate some further Action, for example, a Xinet user uploads a file, then a File Event Trigger is appropriate.
File Events either occur or they don’t. You don’t need to narrow down their trigger points. When the Event occurs, Xinet will run the associated Actions. For Date and Value Triggers, however, you must set some conditions. Once established, the database will verify that the conditions in the rule are met. If they are, then the associated Actions will run following the sequence as established by and listed in the GUI.
No matter how it is triggered, after each Action finishes, it will return information about whether it ran successfully. When the Action finishes successfully, Xinet will execute the next Action in the Trigger Rule. The administrator must specify, when configuring Triggers and Actions, what Xinet should do should an Action fail. The Xinet ADMINISTRATION view presents four possibilities:
If the administrator chooses Continue for the Rule, the next Action (if any) will execute regardless of the success of the previous Action. If the administrator chooses Exit or Exit and Notify, the Trigger Set will not run any further Actions. Exit and Notify will also send e-mail using the On Failure email settings for the Trigger Set.