perform checks and actions when events occur

Event triggers provide a powerful way to customize the application behavior, implementing business rules. Triggers are programs that can be executed upon an object for a large class of events. Most of the events associated with objects and connections, such as creation, deletion, modification of field's values, promotion to another stage, etc. support Triggers.
Triggers can perform checks and actions when an event occur; their associated programs can be written to modify the behavior of many functions, and that behavior can vary depending on the circumstances.
For example a trigger can block an event when a particular requirement is not satisfied or can extend the event action by executing additional operations.
Most of the events associated with objects and links support Triggers. Triggers are added to class, linktype, field and stage definitions in much the same way as fields and methods are added to the class definition, and when used in classes, they are likewise inherited.
With event triggers, it is possible to programmatically guarantee certain events cause (or are replaced by) other actions. For example, when a field value is modified, a connection could occur or when the name of an object is changed, also the names of a related objects are forced to be changed or when an object is promoted to the next stage an email should be sent to some users.

Each event is implicitly wrapped in a transaction boundary and the achievement of a new status is not complete until the transaction is committed (thus ensuring database consistency). When event occurs, a transaction is opened: first of all the check program is executed (if defined), subsequently the action related to the event is performed and finally an additional action program is executed (if defined) to complete the process. If at least one operation fails, the whole transaction will abort.

Triggers can be added to Field, Class, Linktype and Lifecycle-stage definitions; the following table reports the events associated with each kind of administrative element:

For each event in the above table you can create a couple of programs: one for checking if all event's requirements are met and the other to perform additional actions. For example, you can define a trigger-program to check if a Movie was already rented before create a connection between the Movie and a customer, and you can define a trigger-program to progress automatically the Movie object toward the "Rented" stage after the connection was created.
You can also use the same program to regress the Movie back to the "Available" stage as a consequence of the disconnection of the two objects. This is possible because when a trigger-program runs, it receives, as input information, the trigger event type and other additional data that represent the current environment parameters (like object's class, name, revision, current stage, etc. ). The list of trigger-parameters depend on the event type.

A program source code implements the ProgramCode SDK interface.

Refer to the "Program Interfaces" section to know how to write the trigger-program code.

Once created, you can link these programs in the Trigger tab of relative administrative object specifying the event type represented by them.

Tricks: when you need to create a new trigger program, just write the name in the "Filter" text field and double click over it. The form for creating a new program will be opened with the name and program type already compiled.

A event can also start a workflow-process when it occours: if a workflow is associated to a specific event, the new process generated as workflow-instance inherits the object and many of its properties as global parameters (the process holder will be the object holder).

When designing Triggers, programmers should keep in mind that several Triggers may be
fired by what appears to be a single event. For example, a simple object-edit event activate generates a sequence of trigger calls and if defined, a sequence of running processes related to each of them.
Trigger programmers should carefully evaluate exactly where (which event and trigger) their logic should be introduced. Also, remember that if programs exist in many of these Triggers, performance will be affected.

Trigger programmers should also carefully take into account the explicit and implicit trigger recursion to avoid infinite loops. Explicit recursion is when a program execute itself; this type of recursion is easy to spot and is a powerful mechanism when used properly. On the other hand, implicit recursion is caused when a trigger program generates the same event with which it is associated. This form of recursion is more difficult to spot because the running program may be part of a program that was triggered by a totally different event.