This article will be applicable for all existing users of Alert Rules


To provide all users of alert management with the benefits of alert workflows, we will be transitioning your alert rules to alert workflows. This will be done in a phased manner by August 30th, 2024. You will be notified within the product when your account becomes eligible for migration.


Note: The migration will result in the creations of like-for-like equivalent alert workflow for every Alert Rule in your account. For instance, if there are 10 Alert Rules, the migration will result in 10 identical alert workflows being created. 

However, alert workflows can help you simplify the configuration of multiple conditions using nested logic. This means that the 10 Alert Rules mentioned above can potentially be consolidated into fewer, more efficient workflows. 

If you prefer to skip the migration and use this opportunity to consolidate your alert rule logic into fewer workflows, you can sign up for our early access program [here]. Please note that the early access programme will remain open only until July 3, 2024.


Permissions Required

A user must have the 'Manage Workflow Automations, Business Rules, Priority Matrix, and Custom Objects' permission to access alert workflows.

Migration Logic

This article explains the logic used to migrate alert rules to alert workflows.

Alert Rule entity

Converted Alert Workflow entity

Explanation

Alert rule in Workspace A

Alert Workflow in Workspace A

All alert rules in a workspace will be migrated to corresponding Workflow automators within the same workspace.

Alert Rule Name

Alert workflow name

An alert workflow with the same name as an alert rule will be created.

Alert Rule Description

Alert workflow description

Alert Workflow will carry the same description as the corresponding alert rule. 


Workflow Structure

Event Node: An alert rule is executed when:

  • A new alert is created that matches the condition block of an alert rule.

  • An existing alert is updated, matching the condition block of an alert rule.

Hence, the event node of a workflow will contain two events: "Alert is raised" and "Alert log added."

Condition Node: The condition block of an alert rule will translate into one or more condition nodes with the same set of conditions evaluated using 'Match Any' or 'Match All' logic.

Action Node: Depending on the action block of the alert rule, the action node in the workflow will contain one of the following configurations:

  • Create incident with the incident values defined in the alert rule.

  • Create major incident with the major incident values defined in the alert rule.

  • Update alert - Set status as resolved when the action defined in the alert rule is 'Mark an alert as resolved'.

JSON Parser Node: If the condition block of an alert rule has "Additional Information" fields, it will translate as a JSON Parser node containing the additional information field and a subsequent condition node.

Timer Node: If an alert rule has a delay, the corresponding workflow will contain a timer node with the equivalent time delay.

Order of Workflows and Alert Automation Settings

The alert automation settings will be converted into default workflows that can be customized. If the setting is enabled in your account, the workflows will be enabled; otherwise, they will be disabled.

The order of workflows will match the order of alert rules.

Example of Transition

Below is an example explaining the transition from an alert rule to a workflow automator:

The alert rule below will be converted into a workflow automator that looks like the next image


Let’s look at each node one by one:


  1. Event Node: Contains the events “Alert is raised” and “Alert log added” 

  2. Parser Node: Since the alert rule has a condition evaluating the additional info parameter “monitorCondition”, we use the JSON Parser node to parse this parameter. Additional Information block of the alert can now be parsed using the Parser Node.



    The source becomes {{alert.additional_info}} and in the JSON field, we populate the LHS of the condition used in the alert rule.

  3. Condition Node 1: The condition node is set to “Match all of these conditions” and evaluates the integration name and alert severity. 

  4. Condition Node 2: Since the additional information condition is evaluated as “monitorCondition contains Fired or Error”, we create a new condition node with “Match any of these conditions”.

  5. Timer Node: Since the alert rule has a delay of 1 minute for the create incident action, a timer node with a 1-minute delay is added. 

  6. Action Node: We set the action node to “create an incident” and set the incident values as configured in the alert rule


Post-Transition

Once alert rules are transitioned into workflows, alert rules will remain visible in a read-only state for about a week in your account so you can compare and verify them with the alert workflows. After this period, alert rules will be removed from your account.

Click here to know more about workflows for alerts.

If you have any questions, feel free to contact us at support@freshservice.com.