Three may be a workaround provided HPD:INC:ResetKickbackCount does not trigger any filters that sets other fields..

Instead of the set field operation use Direct SQL in the Escalation.

Direct SQL's will not touch the Last Modified Date to the best of my knowledge. The side effect is that they will not trigger any workflow either set for modify action of a filter.

You could try

UPDATE KickBack_Count from HPD:Help_Desk where Entry_ID = "$1$"

z1D Action is a display only field which is set to "RESETKICKBACK", so you would need to check all the filters that run on Escalations that get triggered on this value of z1D Action, and see if those actions can be replicated by direct SQL's too..

That way you could potentially modify the record without touching the Last Modified Date.

ALTERNATELY, created a Last Modified Date2 field that gets set on Modifications only when the user is not AR_ESCALATOR.

Joe

-----Original Message----- From: John Atherly Sent: Monday, March 12, 2012 3:13 PM Newsgroups: public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: "HPD:INC:ResetKickbackCount" Escalation question .... out of the box escalation seems to be updating every incident older than 31 days

I have a report the looks for all Incidents modified in the last 10 days that runs and the escalation called HPD:INC:ResetKickbackCount is killing my report since it modifies all incidents. Does anyone know any thing about kick back.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"

Reply via email to