Review the category-based alerts migration

Stage 1, 2, and 3 alerts and deadline alerts

The Applications Upgrade Utility migrates the Classic Stage 1, Stage 2, Stage 3, and Deadline alerts and Deadline Alert Group configurations from Classic categories to the workflow phases of the automatically-generated Incident workflow.

The migrated alerts are named according to their source. For example, "Incident Alert Stage 1 for complaint" indicates that the alert is converted from stage 1 configuration of the complaint category. The following types of alert are created:

  • Incident alert stage 1 for <category name>. This alert updates the incident alert status to "alert stage 1" if the category has a stage 1 interval or expression specified.
  • Incident alert stage 2 for <category name>. This alert updates the incident alert status to "alert stage 2."
  • Incident alert stage 3 for <category name>. This alert updates incident alert status to "alert stage 3."
  • Incident Deadline for <category name>. This alert updates the incident alert status to "DEADLINE ALERT."

The migrated alerts are located in the alerts tab of each workflow phase.

Gap and limitations

The migrated alerts implement the main functionality of the Classic alerts; however, there are some gaps and limitations.

  • In Classic category-based alert expressions, "$file" represents the incident. The Applications Upgrade Utility automatically modifies "$file" to "$L.file" for compatibility with the migrated alerts. If you use other variables in your Classic system, you must manually modify the expression in the migrated alerts.
  • The timing for the generation of stage 2 and 3 alerts is different. In the Classic Incident module, the schedule for stage 2 is generated after the schedule for stage 1 is executed and the incident alert status is updated to stage 1. Likewise, the schedule for stage 3 is generated after the schedule for stage 2 is executed and the incident alert status is updated to stage 2. In Hybrid mode, however, all schedule records for stage 1, stage 2, stage 3, and deadline alerts are generated or re-generated at the same time, when the incident record is updated.

    Therefore, if you are using an expression that uses the content of the current record ($file) as either the condition or the calculation for the alert time in stage 2, stage 3, or deadline alerts, issues may occur because the content of the current record can differ when the schedule is generated.

  • The migrated alerts are moved to the alerts list of the "In Progress" phase of the migrated Incident workflow. If you add new phases, you need to also add these alerts to new phases so that the alerts can work for incident in the new phases.

  • The alert reset and recalculation conditions in objects are changed in Hybrid mode. Therefore your original alerts may not work. For example, the out-of-box alert reset condition in the Classic probsummary object is category in $L.file="incident" and not (null(1 in external.process.reference in $L.file)). If you use this condition, alerts only work for incidents that are assigned to the incident category. In the migrated probsummary object, the condition is evaluate(nullsub(parse(str(alertsReset in $L.wfPhase), 2), false)) or not (same(current.phase in $L.file, current.phase in $L.file.save)), and the alert reset condition of the "In Progress" phase is set to "true." Therefore, all alerts configured in the phase will work for all incidents rather than only for incidents that are assigned to the incident category.

    In this case, you can modify the schedule condition and the alert condition in the existing alert definition of the Incident Management module by appending the original reset condition that is configured in the Classic object.

Reassignment threshold

The reassignment interval and expression and the reassignment count threshold in the Classic categories are not migrated automatically.

If you still need reassignment threshold functionality, you can add the relevant fields to the new Process Designer-based category file and form, and then copy the configuration to the new Process Designer categories. The following table lists the fields that you will need to add.

Field name in dbdict

Data type

Label in form/description

count

number

Reassign Count Threshold

reassign

date/time

Reassignment Interval

reass.expression

expression

Reassignment Expression