Transactionality of Workflow and Document Event Triggers
The event trigger operation occurs in the following sequence:
• Transaction occurs, and a commitment is made that the pre-event trigger will run.
• Pre-event trigger runs before any modifications have been made to the database. If an error occurs (or a trigger veto) in the pre-event trigger, no changes are made to the database, the transaction is rolled back, and the database is returned to its original state. All scripts, triggers, and assignments are stopped.
• Commit occurs where the change is made to the database.
• Post-event trigger runs only after all data has been committed to disk.
Other items can only be modified by running a chain of pre-event triggers. When the server starts a transaction, the server runs in order: transaction, pre-event trigger chain, commit transaction, and post-event trigger chain.
 | Chains of scheduled triggers run separately from chains of rule-based change triggers. For more information on rule-based triggers, see Creating Rule Based Change Triggers. |
If a pre-event trigger attempts to modify another item or create another item, the secondary item is added to a list of items that become part of the current transaction.
Either all of the modifications made to all of the items must succeed or none of them. This means any pre-event triggers for the secondary item must also run, and they are subject to the same rules as the triggers running for the primary item.
To ensure a pre-event trigger does not run more than once, when the pre-event trigger has completed, other secondary triggers are not permitted to obtain that item again.
All changes made by event triggers bypass the server permission checking. While the history records all changes as having been performed by the user, the trigger is not required to conform to the permissions for that end user.