LJ, Although it's not a feature that I've found particularly useful, your use case sounds like a perfect candidate for an "error handler" filter. If you use one on the target form (of the push) to catch the individual errors, it should allow the whole transaction to succeed.
However, there's another reason the "use a table loop to push to target entries" may not be a good idea...it's not scalable. All of the filters executed in that single run of the escalation's actions count toward the filter limit set for the system. So if the number of target entries might be or grow large, a run of this thing might hit the system limit and abort (and rollback) the entire transaction. If you use the "normal" paradigm and have the escalation running on the target form directly (instead of from a control form), each run of the escalation's actions resets the filter counter, lessening the probability of hitting the limit. -charlie On May 3, 2014 5:48 AM, "LJ LongWing" <lj.longw...@gmail.com> wrote: > ** > Doug/All, > I'll let you know about a 'problem' I have come across with this approach. > Unfortunately, or fortunately, depending on how you look at it, a Push > action requires that all actions on the push succeed for any to be > committed to the DB...so as long as the push encounters 0 issues, > everything is fine. If however, you are using an escalation to process > some records, lets say 100 of them...and 3 of them will generate an error. > If using a Push action from a control form, as described, the escalation > will fire, kicking off the Filter, the Filter will perform the push, it'll > hit the first record that errors out, and the entire action is rolled back, > thus leaving 100 records needing to be modified by the escalation. If > however, the Escalation was making the changes to that record directly, 97 > of the records would be successfully processed, 3 of the records would drop > an error in the arerror.log file, and you would be left with only the 3 > error records. > > So....the two are not unfortunately 100% the same...but similar to each > other, with limitations that may or may not make the use of the control > form viable or not. > > > On Thu, May 1, 2014 at 1:13 PM, Tanner, Doug > <doug.tan...@compass-usa.com>wrote: > >> ** >> >> We use a table/form (i.e. CMN:System Variables) that has one entry with >> multiple attributes, we have a large number of escalations doing many >> different things that look at the CMN:System Variables, and then runs >> appropriate actions on appropriate tables. Works slick! Doug >> >> >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *Ben Cantatore >> *Sent:* Thursday, May 01, 2014 12:18 PM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Self-Terminating/disabling Escalation >> >> >> >> ** Sapna, >> >> Have a flag field as part of the escalation set the flag to true. Make >> the run if qualification for the escalation run on flag equal false. That >> should ensure it only runs once. Otherwise, I'd just create an escalation, >> run it and then remove it manually. >> >> >> >> *Ben Cantatore* >> *Remedy Architect* >> Bed Bath & Beyond >> 650 Liberty Avenue >> Union NJ 07083-8130 >> Office: (908) 613-5769 >> Cell: (914) 263-6802 >> >> [image: LinkedIn] <http://www.linkedin.com/pub/ben-cantatore/3/220/9a7/> >> >> >> >> From: Sapna Motwani <sapana.motw...@gmail.com> >> To: arslist@ARSLIST.ORG, >> Date: 04/30/2014 11:58 PM >> Subject: Self-Terminating/disabling Escalation >> Sent by: "Action Request System discussion list(ARSList)" < >> arslist@ARSLIST.ORG> >> ------------------------------ >> >> >> >> >> Hello Experts, >> >> Please suggest is it possible to define a self-terminating escalation. I >> need to run an escalation just once, and then it should disable itself. >> I want to know is it possible to define an escalation which triggers some >> workflow to mark the calling parent escalation as disable. >> >> Any help would be highly appreciated. >> >> Regards, >> Sapna >> >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> "Where the Answers Are, and have been for 20 years" >> >> "------------------------------------------------------ CONFIDENTIALITY >> NOTICE: This e-mail, and any attachments thereto, is intended only for use >> by the addressee(s) named herein and may contain confidential information. >> If you are not the intended recipient of this e-mail, you are hereby >> notified that any dissemination, distribution or copying of this e-mail, >> and any attachments thereto, is strictly prohibited. If you have received >> this e-mail in error, please permanently delete the original and any copy >> of any e-mail and any printout thereof. Thank you for your compliance." >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> This email is subject to certain disclaimers, which may be reviewed via >> the following link. http://compass-usa.com/Pages/Disclaimer.aspx. >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
