<< Click to Display Table of Contents >> Defining Alerts |
When executing a Process, the duration of Tasks must be controlled to adhere to the organization's compliance metrics, manage process times, and allow for decision making to enhance process performance
In order to do so, Bizagi provides a tool that allows you to generate warnings for different people when a Task is about to expire, expires or has expired.
Alerts in Bizagi are triggered as email notifications. A message is sent to a specified person to inform the status of a Task and thereby prompting the necessary actions to complete the pending Activity.
Notification alert emails can be customized. If the default template is not used for the Bizagi alerts, then a new template can be created to use the alert feature. The configuration of these alerts is flexible in regards to time and recipients.
Alerts are set-up from the Work Portal by end users, using the Admin – Process Management - Alerts option in both the Development or Production environment. Changes to alerts are local to the Production environment. If you want those changes to be permanent and become part of the process design, you must make them on the Development environment as well.
How to Set Up Alerts
1. In the Work Portal, click Admin, open the process management category and then Alerts.
2. Choose the Applications, Process and Task where you want to create or edit the Alert; then click Alerts>>.
3. In the Alert Editor Screen you can set up the time, recurrence, Lapse and target groups of the Alarm. The Alarm Editor has the following features:
•Alarm Recurrence: Is the recurrence of the alert once it has been executed for the first time, that is, the number of repetitions.
The types of recurrence offered by Bizagi are:
oNone: The alert will go off just once without repetition.
oEach Recurring Time: The alert will go off every certain amount of time defined using the Interval feature.
oEach Task or Process Time: The alert will go off and repeated each time the task duration runs out.
•Lapse: is used to define the time lapse until the alert executes for the first time. This feature is always required regardless of the type of alert selected.
The following options are available:
oBefore Expiration: The alert will be executed for the first time a certain time before the duration established for the task has run out.
oOn Expiration: The alert will be executed for the first time once the duration established for the task has run out.
oAfter Expiration: The alert will be executed for the first time a certain time after the duration established for the task has run out.
If you select the Before Expiration or After Expiration options, you must define the time before or after the expiration in the Timing property. |
•Timing: In this section you must define the time for lapse of execution and recurring time:
oLapse(min): Is used to define the execution time (in minutes) of the first alert taking the Task expiration time as a point of reference. This time must be defined when the lapse selected for the alarm is Before Expiration or After Expiration.
oRecurring Time: Allows you to define the alert recurrence time when the type of alert selected is Each Recurring Time. You can select the measure unit of the combo: minutes, hours, days, weeks or months.
•Recipients: Recipients allows you to define the recipients of the alert. One alert can have one or more recipients. You can add Recipients once the alert has been created.
To choose the recipient, you can determine the recipient’s profile by selecting a role from the combo and then clicking Add Recipient.
To delete recipients check the Recipient Email box for every recipient you wish to remove from the list and then click Delete selected recipients.
You can also set up the distribution of the alert to the current user of the activity by checking the field Send to current assignee.
Delete or Edit an alert from the Work Portal
Once the alert is created you can find a list with the alerts for each Task. You can delete or edit alerts from there. To do so press the Edit or Delete button. When done the Alert List will update automatically.
Alerts in New Process Versions
When you create a new process version, and you deploy it to test or production environments, existing Alerts of the previous active version are cloned and deployed automatically. Refer to Deployment of processes and new versions. For example, you create an alert in a specific task in the 1.0 version of a process:
With the following characteristics:
Later you create a new version of the process:
Then you deploy this new version. The alert is cloned and persist as created in the previous version in the target environment:
If you have multiple versions, Alerts are always cloned from the last active version in the target environment. Additionally, Alerts are cloned considering as follows:
•The task related to the alert must exist in the new deployed version. If there is a new task then you must manually add the alert in the new process version.
•The name of the task related to the alert must be the same in the new deployed version.
Suppose that there are three versions 1.0, 1.1, and 1.2:
Scenario |
Expected behavior |
---|---|
Cloning of all the alerts: Each time that you create a new process version it inherits all the previous active version alerts (If all the tasks preserve the same name). |
All the alerts configured for the tasks of a previous active version 1.0 are replicated on all the corresponding activities of the new process version 1.1.
NOTE: The cloning of alarms happens when you deploy the new process version to a target environment (e.g. Test or Production). Alerts are NOT cloned in the development environment. |
Multiple process versions: The alerts configuration of the newest process version is inherited from the previous active version. |
All the alerts configured for the tasks of a previous active version 1.0 are cloned on all the corresponding activities of the new process version 1.1. All the alerts configured for the active version 1.1 are now cloned in the version 1.2 and so on.
NOTE: The cloning of alarms happens when you deploy the new process version to a target environment (e.g. Test or Production). Alerts are NOT cloned in the development environment. |
Last Updated 1/23/2023 12:05:12 PM