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"