Event triggers

Introduction to event triggers

Event triggers are interrupts which signal that a certain event has occurred for a case. They are attached to scopes. A scope can have several event triggers. Event triggers can react to all kind of changes, for example changes to case data, the assignee or the relations of the case. The actions which should be performed when the event occurs need to be scripted in an automatic activity connected to the trigger.

Examples for the use of event triggers:

Set an overlay if a comment was added by the customer or a user who is not assigned to the case.
Recalculate the value of a field which is based on the values of other fields if there are changes to these values.
Automatically move a case forward in the business process when the value of a certain field has been changed.

Process logic with event triggers

The following general logic applies to event triggers:

The event defined in the event trigger occurs for a case in the scope where the trigger is attached.
The trigger fires, i.e., it signals that the event has occurred.
The script defined within the trigger is executed. If it returns true, the following automatic activity or decision node with two following automatic activities is executed.

If a change affects more than one case parameter and different event triggers have been defined for these parameters at the scope, the event triggers fire according to their order at the scope, from the left to the right. If an automatic activity causes the case to leave the scope where the triggers are attached, e.g., by moving it to another queue with a jump-out node, the other triggers do not fire.

If there are event triggers which react to the same change in nested scopes, the event is handled by the trigger in the innermost scope. If the trigger in the innermost scope does not react to all the events which occurred, the events which have not been handled yet, are passed to the next outer scope.

Best practice:

Attach the event trigger to the innermost possible scope to avoid unnecessary trigger executions.
If there is an activity which modifies certain case data and a trigger reacting on these changes should not be executed, move the activity outside the scope where the trigger is located.
The automatic activity which follows an event trigger should not make any modification to the case parameters which the trigger reacts to. This would cause a loop as the trigger would fire again after its activity has been executed. If modifications to the case parameters which a trigger reacts on are required, move the activity outside the scope where the trigger is located.

Available settings for event triggers

The following settings are available for event triggers:

Path:
Read-only. The path to the event trigger within the workflow. Used to reference the trigger in scripts.
Queue:
Optional. If checked, the trigger fires if the case is transferred to another queue. It is not relevant if the change was performed manually by a user or automatically by the system.
Assignee:
Optional. If checked, the trigger reacts on changes of the assignee of the case. This includes assigning a previously unassigned case to a user, assigning a case to a different user, or removing the user from the case.
Subject:
Optional. If checked, the trigger fires if the case subject is modified.
Communication:
Optional. If checked, the trigger reacts on changes to the communication in the case history, i.e., a new comment was added in the Web Client or CM/Track, an email was sent or received, an attachment was added or a text class was changed.
Participant:
Optional. If checked, the trigger reacts on changes to participants. This includes adding participants to a case or removing participants from a case.
Related resource:
Optional. If checked, the trigger reacts on changes to related resources, i.e., a resource relation is created, removed or modified.
Related case:
Optional. If checked, the trigger reacts on changes to related cases, i.e., a case relation is created or removed. The trigger fires separately for the source and the target case of the relation.
Time booking:
Optional. If checked, the trigger fires if a new time booking entry was added.
Case field:
Optional. The trigger reacts on changes to the selected case fields. You can select one or several fields of different field groups. It is also possible to select all the fields of a case field group.
Script after event:
Optional. Determines if the subsequent automatic activity is executed. The script is executed when the trigger has fired. It has to return true (the activity is executed) or false (the activity is not executed). This allows a more detailed control about the activity execution, e.g., to react only if a certain value is set for a case field.

Best practice

Use this script only to determine if the automatic activity is executed or not. All other actions should be performed in the script of the automatic activity connected to the trigger.

Programming with event triggers

You can obtain an object of the type TicketChanges which contains the modifications done to the case:

workflowApi.getTicketUpdateEvent().getModifications()