Types of Triggers

Each supported data event has three types of triggers.

  • Check trigger that fires before the event occurs
  • Override trigger that can replace the event transaction
  • Action trigger that fires after the event occurs

For each event, Programs can be specified for none, any, or all of the Trigger types.

The following topics are discussed:

Check Trigger

The check trigger executes first, before any of the normal system code which carries out the event has a chance to execute.

The program specified here can be used to:


  • Perform pre-event processing in anticipation of the event
  • Block the event from actually occurring, aborting the event transaction, which means that no other trigger programs are get executed.

Refer to Types of Trigger Programs for more information.

Override Trigger

The override trigger fires after the check trigger, but before any of the normal system code that carries out the event has a chance to execute.

It can also be used to:


  • Perform pre-event processing after any check program has decided not to block the event.
  • Replace the normal event processing with an alternate event.
  • Perform a soft block on the event., meaning that the event is blocked without raising an exception, the action program is executed and any pre-processing done in the check program is not rolled back.

Refer to Types of Trigger Programsfor more information.

Action Trigger

The action trigger fires after the event transaction is committed, whether the normal event took place or the override program replaced the event.

The action program typically extends the functionality associated with an event (or the override program that replaced the event). A program attached to the action trigger can perform any post-event processing that must be done after the event has updated the database. For example, an action program may generate a report in an external application that lists the changes that have just occurred. Since you would not want this action to fire unless those changes actually took place, the action trigger is always fired after the event transaction is committed.

Consider, however, that the same event is part of a larger transaction. If the action trigger fired immediately after the event, generating a report outside of the ENOVIA Live Collaboration, what would happen if the transaction failed? The ENOVIA Live Collaboration can only roll back internal state changes, so the report would be generated erroneously. In this case, the action program execution should be defined as Deferred so that it is deferred until all transactions are committed.

Refer to Types of Trigger Programs for more information.