Given that Bizagi 11 opens the door to managing data like never before, a new feature called triggers, is introduced to help you react on real-time whenever there are changes in the data.
For detailed information on the data managing features and overall new concepts in Bizagi 11, refer to Experience design.
Triggers run automatically in the background (i.e, performed by the Scheduler) as a response to certain events in the underlying data.
Similarly to the concept of database triggers, in Bizagi these triggers may react if there is a new record created or a modification in an existing one (i.e, insert or update clauses).
The image above illustrates the concept of how triggers listen to events, and how they will make something run, upon a detected change.
An example on the use of triggers, can be seen when we want to activate a special procedure for a customer, right after he/she has become a VIP customer.
If we define that a customer can become VIP due to several reasons, such as: completing a purchase that tops a predefined amount, redeeming a promotional voucher, or simply because a new policy came out with which the customer is now marked as VIP (his/her information being eventually updated), we may decide to use a trigger as a best practice.
In this scenario, a trigger will allow you to:
•Keep process models tidier, without needing to include BPMN/logic in them that validates for VIP customers.
•Rely on an optimal event-driven mechanism in which Bizagi reacts efficiently to changes in data in real-time, instead of having to perform periodical validations regarding if a customer has become VIP or not.
•Provide additional options in the Work portal, such as the possibility to update customer information in forms directly, while keeping best maintainability in the solution -focused entirely on the configuration of the trigger.
In addition to this, the procedure a trigger can activate for a VIP customer may be as simple as updating applicable information (e.g, increasing the discount percentage used in his/her purchases), or as sophisticated as launching a complete process (e.g, to approve or send him/her a promotion code or a new pre-approved product offering).
This means that a trigger may simply execute a business rule or event start a whole new process.
When defining a trigger, consider that its configuration is done directly at the entity on which the trigger will listen to changes.
Recall that a trigger is executed when either of these events happen:
•A new record of a specified entity is created.
•An existing record of a specified entity is modified.
For either of the above, you may define that such record meets with a condition you define (evaluating such condition for that record returns true).
The trigger will the execute one of the options below:
1. Launch a process (create a new instance of a process).
2. Execute an expression.
In either cases, Bizagi will automatically inject the information it has available.
In the first case, Bizagi will automatically inject in the Process entity the information of the record that caused the trigger. Thus, in order to inject such record, the Process entity must have a foreign key that references the triggering entity.
In the second case, the context of the expression will be automatically set at the entity of the record that caused the trigger.
In order to define a trigger, go into the Expert view and click Entities.
Locate the given entity and go into its Triggers item.
Right-click to select new trigger.
Notice that both when creating or editing triggers, the following properties are presented for configuration:
A descriptive name for you to identify and look up the trigger.
This name is shown in the list of triggers for a given entity.
Determine when will the trigger be launched by considering marking the following checkboxes.
•A new record of the entity is created: Upon the creation of a new record in a given entity.
•A record of the entity is updated: Upon modification of a record in a given entity.
One or both options can be selected.
Select a Boolean expression that sets the condition which a record must meet, for the trigger to take place.
You may use the icon to create a new expression at this point.
It's mandatory to set a condition rule.
Define if the trigger will start a new process or if it will execute an expression by selecting either of the following options.
•Launch a new case for the following process: Choose the process from the drop-down list, or alternatively use the icon to create a new process definition at this point.
•Execute an expression: Choose the expression from the drop-down list, or alternatively use the icon to create a new expression at this point.
When done, click OK to save changes.
Triggers are mainly classified according to the 2 types of action they can target.
Refer to the child topics below for an example on how to configure each of the 2 scenarios.