Is this a filter phasing issue? Usually, all set fields actions fire first, then all push fields actions to ensure data integrity. If one of the set fields actions fail, there are no records updated or created with the push fields action. With filters you can change this behavior by adding `! (backtick exclamation mark) to the filter name, I do not think that option works for escalations.
Try creating the escalation with only the first push fields action. Create a filter that in this case (on create and $USER$ = "AR_ESCALATOR" or the like) pushes the HD request back to the original form and set the field from No to Yes. Good luck, -- Met vriendelijke groet / Kind regards Michiel Beijen ______________________________________________________ MANSOLUTIONS Energieweg 60-62 3771 NA Barneveld The Netherlands Tel. +31-(0)612968592 Mail [EMAIL PROTECTED] Internet http://bsm.mansolutions.nl On 10/1/07, Pickering, Christopher <[EMAIL PROTECTED]> wrote: > > ** Joe, > > There are no filters firing on this. Only 2 escalations, one for US and > one for Row. Each escalation has 3 actions. > 1. A push field taking data from the original form and pushing to Help > Desk with a 1=2 qualification. > 2. Takes the HD request ID and sets it back to the original form. > 3. Sets a single field from No to Yes in the original form acknowledging > that the data was acted upon via the escalation. > > This is the run if on the escalation: ( 'Acknowledged' = "No") AND ( > 'Location' != "EU_SuperNode" ) > > C > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Joe D'Souza > *Sent:* Monday, October 01, 2007 12:50 PM > *To:* [email protected] > *Subject:* Re: Escalation creating dup tickets > > ** Chris, > > What is the workflow behind the creation of the ticket? > > I mean when the Escalation fires, is the Escalation directly creating that > ticket? Or is a Filter set to fire on that Escalation create that ticket? > > What are the exactly actions on your Escalations as well as filters > created to fire on that Escalation? > > It definitely isn't a problem with the Server Groups. Server groups allow > for only one Escalation server within the server group. > ** > *Joe D'Souza* > > -----Original Message----- > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] Behalf Of *Pickering, Christopher > *Sent:* Monday, October 01, 2007 12:24 PM > *To:* [email protected] > *Subject:* Escalation creating dup tickets > > ** > > Hello all, > > Has anyone seen where a single escalation fires and creates matching > tickets where the only difference is the Request ID? In the logs, it shows > the escalation firing, doing a push to ITSM (Help Desk), does a return > setfield back into the original form that a second setfield changes the > value which triggered the escl firing in the first place, then immediately > there after, with no escalation fire a second Help Desk Desk ticket is > created with a sequential requestID. > > This is in a server group, but I have confirmed that the escalations are > only firing on one of the 3 servers. > > ARS 6.3, CSS 5.01, ITSM 6.0, Solaris 5.9, Sybase 12.5.3. > > C > > > Christopher H. Pickering > Remedy System Administrator > Premiere Global Services, Inc. > 100 Tormee Drive > Tinton Falls, NJ 07712 > 732.389.3900 X2411/800.333.0568 X2411 > [EMAIL PROTECTED] > www.premiereglobal.com > > ** > > __20060125_______________________This posting was submitted with HTML in > it___ > __20060125_______________________This posting was submitted with HTML in > it___ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
