Event dependencies by trigger
Events are evaluated in the order of event dependencies within each trigger. Events that are referenced by another event are evaluated before the dependent event is referenced.
In the following diagram, you can see event dependencies that are permitted
by trigger. For each trigger listed in the leftmost column, the table
displays the triggers containing events that can be evaluated as a
condition in the event trigger in the left column. Read the table
in the following manner: Events in event trigger
<Column 1> can use as conditions the events that are available
in trigger(s) <Column 2> - <Column 6>.
Can Depend on Events in trigger -> Event trigger: | First Hit | Every Hit | After Every Hit | Last Hit | End of Session |
---|---|---|---|---|---|
First Hit | Y | ||||
Every Hit | Y | Y | Y | ||
After Every Hit | Y | Y | Y | ||
Last Hit | Y | Y | Y | Y | |
End of Session | Y | Y | Y | Y | Y |
Circular dependencies
Events whose output is used as an input for the event itself create circular dependencies. The Event Manager does not prevent the specification of circular dependencies through the UI, even though they cannot be resolved.
Below are examples in which event outputs are used as the conditions (inputs) for other events:
event A > event A
event A > event B > event A
event A > event B > event C > event A
All of the above references are flagged as errors in the following locations:
- Event Tester when any of the events are tested Note: If you pass newly created or edited events through the Event Tester, any circular references are flagged for review and correction. During event execution, an error is logged in the system event log, and the event is never evaluated. See Event Tester.
- canister reports an error message in the system event log when event definitions are loaded
- error message logged in system event log during execution