Processing Triggers on the Stack
Learn how to process triggers on stack.
An event can initiate several triggers, which in turn can initiate further triggers, see Trigger Chains and Branches. Aurea CRM stores the triggers on an internal stack. Whilst a trigger is being executed, any number of other triggers can be stored on the stack waiting to be processed.
If the execution of a trigger initiates a further trigger, the new trigger is added to the top of the stack ("First In First Out"). This behavior can be changed globally using a configuration entry (Log triggers) or per trigger in the access rights definition (Execute follow-up triggers recursively option), see Recursion Depth.
Trigger conditions (see Defining Database Events) are tested when triggered, and not before the trigger is actually executed. However search conditions (see Defining Triggers) are only tested once the trigger is actually executed.
The situation in which the trigger was initiated is also stored on the stack: which records need to be edited or deleted; or from which record new records should be added.
When executing triggers, Aurea CRM's multi-tier system of access rights applies, see Rights Hierarchy. Triggers defined in the station access rights are initiated first, followed by those in the group and rep access rights, and finally those in the role access rights. If you are inheriting access rights, you can configure this behavior for each trigger, see Further Settings for Triggers and Workflows.
Trigger Chains and Branches
It is possible to define chains of triggers, with one trigger calling the next. Take care to avoid infinite loops: If you want one or more triggers to be initiated repeatedly, ensure that process also terminates at some point (Suppress subsequent triggers option).
If you want to call several external programs or transfer several records to the word processor at once, you can define dummy triggers. The dummy trigger applies a change to a specific field which in turn initiates the trigger containing the program call or used to transfer data to the word processor.
Triggers containing the actions Program Call, Single/serial letter, WEB level or E-mail cannot initiate other triggers, as they do not apply any changes to the database.
Recursion Depth
The recursion depth determines the depth up to which follow-up triggers are processed directly and not added to the stack.
In the following example, a database event initiates triggers 1 to 3. Trigger 1 updates 2 records (X and Y), the remaining triggers update a single record each. The triggers 1a, 1b and 2a are follow-up triggers that are initiated by the changes applied using the first trigger.
The orange lines depict the order in which triggers are executed; the large blue rectangle represents the stack.
Recursion depth 1 (default in Aurea CRM win):
Recursion depth 0 (default in Aurea CRM web):
You can configure the default recursion depth globally or per station using a configuration entry (Log trigger). The maximum recursion depth is 100.
Recursion depth 2:
You can also determine whether follow-up triggers or workflows are executed recursively or not for each trigger/workflow, see Further Settings for Triggers and Workflows.