Generate Triggers Job Only Uses "OR" Logic when Creating Triggers

Generate Triggers Job Only Uses "OR" Logic when Creating Triggers

While creating the Generate Triggers job, it is observerd that all the triggers are created with "or" logic even though their policies contain a series of "anded" criteria.

This is the expected behavior.

The triggers created for multiple conditions of one policy with "or" logic is expected behavior.

The reason for this is to separate the functionality of Generate Triggers (Gentrig) and Workflow Monitor (WorkMon) Components. Gentrig is a relative simple Server Component that monitors DB record changes and inserts a record of these changes into S_ESCL_REQ. WorkMon then evaluates the inserted record (violation) and checks to see if all the conditions associated with Rule of the violation are met.  Only if all conditions are met, does WorkMon then fire the associated action for the policy.

Architecturally, it is more efficient to have WorkMon evaluate the conditions associated with a violation rather than having a complex trigger mechanism.  Additionally, because condition data is often stored in more than 1 table; and because a series of conditions that cause a violation of policy can occur at separate times while still within the monitor action interval, capturing these with database triggers is very difficult -because database triggers can only fire for concurrent actions.  As a result of this database limitation, it becomes important to capture all of these potential violations in order to have WorkMon evaluated them as a whole at the time of the policy action.

For example, a policy has 2 conditions: SR area=Network and Activity Priority=1-ASAP. 2 triggers will be generated. One trigger monitors SR being created or updated, and checks to see if the area equals Network. The other trigger monitors Activity records being created or updated, and checks to see if the Priority equals 1-ASAP. If we created AND triggers, and a user creates a SR without Activity, since the activity is not there, the trigger will not be violated. Later, a user adds an activity to the SR, but because the trigger created was using an "AND" trigger, and in this instance the main SR record is not updated, still no database trigger fires. The violation would then be lost as no trigger would be fired in either instance due to the anded logic.
However, if the OR logic exists for the triggers, then there will be 2 records inserted into S_ESCL_REQ (1 for the SR area Network added/upated, 1 for the Priority 1 activity added)  Because workMon will evaluate each record as it is inserted, the condition would not evaluate as a violation until the activity is added (the second record).  Therefore, the first row would be discarded (as there was no activity), but the second insert would cause a violation and the action would fire because at that time, both the SR Area and the Activity Priority meet the policy conditions.

So, as you can see when you look at the architecture in its entirety, even though the triggers are generated with "or" logic, the WorkMon component will evaluate the entire rule as a whole before deciding whether or not it is appropriate to fire off the workflow.

Please note that Modifying triggers manually is not a supported practice.