**

Listers,



I am hoping someone can provide input on this one. A clobber filter was created to run before an unset filter. Filter 1 is supposed to clobber records that have passed the escalation time while the ticket was 'on hold' or 'service available' status.



Filter 1:

* Description - "clobber filter that runs before the unset (SLA:TT:m520:Unset SLAs On Hold) filter. This filter will clobber the telalert records that have passed the escalation time while on hold or in service available."
* Execution order - 495
* Execute - on modify
* Run if - (( 'TR.Status' > 'DB.Status') AND ( 'DB.Status' = "Service Available") AND ( 'Quick Ticket?' != "Yes")) OR (( 'TR.Status' > 'DB.Status') AND ( 'DB.Status' = "Monitor/On Hold") AND ( 'Quick Ticket?' != "Yes"))
* Action - Push field if ( $Trouble Ticket$ = 'TT Number') AND ( 'Time to Escalate' < $TIMESTAMP$) AND ( 'Status' = "Not Sent") AND ( 'On Hold' = "Yes") AND ( 'Time to Escalate' > ( 'Create Date' + 50)) and sets 'escalate' field to $NULL$





Essentially, Filter 2 temporarily holds notifications if ticket status is Service Available or Monitor/On-hold.



Filter 2:

* Description - "If the ticket is pulled out of Monitor/On Hold this filter un-sets a flag on the TelAlert form which will allow escalations to proceed as normal.

Note: any records past their regularly scheduled escalation time will immediately send out notifications."

* Execution order - 520

* Execute - on modify

* Run if - ( 'DB.Status' != 'Status') AND ( 'Status' != "Monitor/On Hold") AND ( 'Status' != "Service Available") AND ( 'Quick Ticket?' != "Yes")

* Action - Push field if ( $Trouble Ticket$ = 'TT Number') AND ( 'Status' = "Not Sent") AND ( 'Escalate' != $NULL$ ) and sets 'on hold' field to $NULL$.



The following is true of Filter 2:

* If the next status after Service Available or Monitor/On-hold is Resolved, pending notifications are clobbered.
* If the next status after Service Available or Monitor/On-hold is Open or Assigned, any past due notifications are immediately sent. This results in sev 3 tickets sending notifications during non-business hours. For example, if a sev 3 ticket on-hold is moved to open on Saturday, it will send the missed Resolution SLA page even though sev 3 notifications normally sent during business hours (m-f 8-5) only. The Resolution SLA is usually breached sometime during the on-hold status, but it's not actually sent until the status changes. This led to the development of Filter #1. The problem is that is works most of the time but not all of the time. For some odd reason people don't usually enjoy waking up to a sev 3 page on the weekend for no real reason (go figure!).



Sorry for the lengthy explanation but can anyone see inherit flaws with this workflow? Or at least help provide some input.?



Thank you in advance!

Richard





This posting was submitted via the Web interface