Highlighted
Established Member..
Established Member..
1646 views

Incident Alert Status

Jump to solution

Hi,

 

Can anyone explain to me what is the flow or differences between the alert statuses below (esp. the "Updated" status):

 

1. Alert Stage 1

2. Alert Stage 2

3. Alert Stage 3

4. Deadline Alert

5. Updated

 

Thanks in advance!

0 Likes
1 Solution

Accepted Solutions
Highlighted
Absent Member.. Absent Member..
Absent Member..

The internal IM alert engine works as follows:

 

At open, the status is open.

Once updated by a user, the status changes to updated

If two-step close is used, at resolved it changes to resolved.

At closure is changes to closed.

At reopen, it changes to reopened.

 

When the ticket is opened or whenever a user updates the record, the alert timers reset. (The best way to describe the IM alert process is that it's purpose is to flag records which are not updated regularly so that they are not missed--THAT IS ALL IT DOES).

--You can configure notifications at each alert stage.

--The assignment group can change automatically when stage 2 or stage 3 is reached if you define alert stage 2 groups and alert stage 3 groups in the assignment group records (I don't know if this actually will work automatically OOB anymore, it may require tailoring, so test if you want to use it. I may still work but I haven't used it in years).

  

If alert stages are defined in the category record, they are applied as follows:

For this example, let's say the alert stage 1 interval is 7 days, the alert stage 2 interval is 3 days, the alert stage 3 interval is 3 days and the Deadline Alert interval is 30 days.

 

ALERT STAGE 1, 2, and 3 ALWAYS and ONLY relate to UPDATE.TIME. They cannot be based on any other field. 

--If a record is not updated by the interval specified for alert stage 1, the status is changed to "alert stage 1" and the alert stage 2 interval starts.

--Whenever a user updates the record, the timer for alert stage 1 resets.

 

--Once at alert stage 1:

  • If someone updates the record, the alert 1/2/3 stage timers are reset and the status is set back to updated.
  • if no one updates the record and the alert stage 2 interval passes, then the status changes to "alert stage 2" and the alert stage 3 interval starts. Note that this means that to reach alert stage 2 in the example, the ticket must reach alert stage 1 (7 days) AND then not be updated for another 3 days (the alert stage 2 interval) to hit alert stage 2

--Once at alert stage 2:

  • If someone updates the record, the alert 1/2/3 stage timers are reset and the status is set back to updated.
  • if no one updates the record and the alert stage 3 interval passes, then the status changes to "alert stage 3". Note that this means that to reach alert stage 3 in the example, the ticket must reach alert stage 1 (7 days) AND then not be updated for another 3 days (the alert stage 2 interval) to hit stage 2 AND then not be updated for another 3 days (the alert stage 3 interval) to hit alert stage 3. So the ticket would not have been updated for 13 days.

--Once at alert stage 3

  • if a user updates the record, the status is set back to updated and the alert stage 1 timer starts running. 

DEADLINE ALERT is different.

The deadline alert is ALWAYS measured against open.time. If a ticket is open for longer than the Deadline Alert interval (here 30 days), the status is changed to "DEADLINE ALERT" and cannot be changed unless the record is closed. Essentially you're saying that no ticket should be open lger than this period of time.

 

NOTE: when SLA-based alerts are configured, they update the status field using these values differently. (E.g. the alert at breach will mark the status as DEADLINE ALERT.) These explanations apply only to the category-based alerts. If you've licensed the SLM Module, HP's best practice recommendation is to use SLM-based alerts instead of the legacy category alerts.

 

If you want to set more flexible intervals (e.g. time interval to vary by IM Priority) you can calculate the interval using the alert interval expressions rather than entering a fixed duration.

 

The biggest "mistake" I run into when customers initially define alert intervals is setting them far too aggressively. They work best when configured to identify exceptions more extreme cases. If set too aggressively, people start to ignore them.

----------------------------------------------------
Kudos - what, where, how, and why
Want Good Answers? Ask Good Questions...

View solution in original post

3 Replies
Highlighted
Absent Member.. Absent Member..
Absent Member..

The internal IM alert engine works as follows:

 

At open, the status is open.

Once updated by a user, the status changes to updated

If two-step close is used, at resolved it changes to resolved.

At closure is changes to closed.

At reopen, it changes to reopened.

 

When the ticket is opened or whenever a user updates the record, the alert timers reset. (The best way to describe the IM alert process is that it's purpose is to flag records which are not updated regularly so that they are not missed--THAT IS ALL IT DOES).

--You can configure notifications at each alert stage.

--The assignment group can change automatically when stage 2 or stage 3 is reached if you define alert stage 2 groups and alert stage 3 groups in the assignment group records (I don't know if this actually will work automatically OOB anymore, it may require tailoring, so test if you want to use it. I may still work but I haven't used it in years).

  

If alert stages are defined in the category record, they are applied as follows:

For this example, let's say the alert stage 1 interval is 7 days, the alert stage 2 interval is 3 days, the alert stage 3 interval is 3 days and the Deadline Alert interval is 30 days.

 

ALERT STAGE 1, 2, and 3 ALWAYS and ONLY relate to UPDATE.TIME. They cannot be based on any other field. 

--If a record is not updated by the interval specified for alert stage 1, the status is changed to "alert stage 1" and the alert stage 2 interval starts.

--Whenever a user updates the record, the timer for alert stage 1 resets.

 

--Once at alert stage 1:

  • If someone updates the record, the alert 1/2/3 stage timers are reset and the status is set back to updated.
  • if no one updates the record and the alert stage 2 interval passes, then the status changes to "alert stage 2" and the alert stage 3 interval starts. Note that this means that to reach alert stage 2 in the example, the ticket must reach alert stage 1 (7 days) AND then not be updated for another 3 days (the alert stage 2 interval) to hit alert stage 2

--Once at alert stage 2:

  • If someone updates the record, the alert 1/2/3 stage timers are reset and the status is set back to updated.
  • if no one updates the record and the alert stage 3 interval passes, then the status changes to "alert stage 3". Note that this means that to reach alert stage 3 in the example, the ticket must reach alert stage 1 (7 days) AND then not be updated for another 3 days (the alert stage 2 interval) to hit stage 2 AND then not be updated for another 3 days (the alert stage 3 interval) to hit alert stage 3. So the ticket would not have been updated for 13 days.

--Once at alert stage 3

  • if a user updates the record, the status is set back to updated and the alert stage 1 timer starts running. 

DEADLINE ALERT is different.

The deadline alert is ALWAYS measured against open.time. If a ticket is open for longer than the Deadline Alert interval (here 30 days), the status is changed to "DEADLINE ALERT" and cannot be changed unless the record is closed. Essentially you're saying that no ticket should be open lger than this period of time.

 

NOTE: when SLA-based alerts are configured, they update the status field using these values differently. (E.g. the alert at breach will mark the status as DEADLINE ALERT.) These explanations apply only to the category-based alerts. If you've licensed the SLM Module, HP's best practice recommendation is to use SLM-based alerts instead of the legacy category alerts.

 

If you want to set more flexible intervals (e.g. time interval to vary by IM Priority) you can calculate the interval using the alert interval expressions rather than entering a fixed duration.

 

The biggest "mistake" I run into when customers initially define alert intervals is setting them far too aggressively. They work best when configured to identify exceptions more extreme cases. If set too aggressively, people start to ignore them.

----------------------------------------------------
Kudos - what, where, how, and why
Want Good Answers? Ask Good Questions...

View solution in original post

Highlighted
Established Member..
Established Member..

Hi John,

 

Thanks for the detailed explanation. Appreciate it much !

Best Regards,
KH Ng

0 Likes
Highlighted
Absent Member.
Absent Member.

Hi John,

 

I have the requirement to send an alert if the IM ticket is not updated for 3 days. I configured the alert with the below values

 

Special ALert Type: Standard
Alert Status: Alert Stage 1
Schedule Condition:true
Alert Condition:true
Calc Field:open.time
Calc Interval: 1 00:00:00

but nothing is happening. Can you please help me with the Issue. What is missing here

 

-DK

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.