Re: Escalation trigger filters without modifying records?
Hi Brien What you are describing is definitely *not* a normalized data structure as you are storing and maintaining the linked data in your main form... but leaving that aside. The suggestion from Fred would work for small data volumes, but as soon as you are updating larger volumes you will have performance problems and hit the AR server filter limit, so assuming you still need the scheduled escalation to sync your data... Create your own Modified Date and Last Modified By fields and set values in these fields through a filter when the record is created or modified where $USER$ != AR_ESCALATOR. Then in your form display your custom fields instead of the core fields. HTH David Sanders Solution Architect Enterprise Service Suite @ Work / e-ServiceSuite tel +44 1494 468980 mobile +44 7710 377761 email david.sand...@westoverconsulting.co.uk web http://www.westoverconsulting.co.uk http://www.e-servicesuite.co.uk ITIL SaaS On Premise -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: 10 February 2012 03:03 To: arslist@ARSLIST.ORG Subject: Re: Escalation trigger filters without modifying records? If your normalization happens on every save of the record then are you having to run thru them on a schedule to update them because something somewhere else changed? i.e. If you are setting a Name field in Form AAA on save, are you trying to keep that Name field in sync with a Name somewhere else (like on Form BBB)? I would look at trying to detect when the source of Name (Form BBB) is changed and force the related records (Form AAA) to update at that time. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle Sent: Thursday, February 09, 2012 6:13 PM To: arslist@ARSLIST.ORG Subject: Escalation trigger filters without modifying records? I've got a lot of filters that do some normalization by setting some key fields via a lookup. This might be a bad idea, but I generally create escalations that do some tidying up-- they just blast through all the records and update a trigger field to trigger the modify filters. Having all the records last modified by AR_ESCALATOR is starting to irritate some of my colleagues, so I'd like to stop doing this. Any thoughts? I've tried several ways to get an escalation to trigger the modify actions without actually modifying the record-- without any success. I also definitely do not want to duplicate the code in the modify actions and copy them into the escalation. Thanks! Brien ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Escalation trigger filters without modifying records?
What Fred is saying is avoid the escalation by including your normalization at time of save or in his second case at time of save of another form (with a non AR_ESCALATOR user). (Sorry Fred. Just wanted to make that a bit clearer). The ONLY way to modify a record without changing the fields modifier and modified time is through the Merge API which is not doable by workflow. It is certainly doable with other methods like a Meta-Update script, your own code in a binary etc. ARS always performs the save when fields that set the dirty bit are set - even if they are set to the same value. Ie: db.f = 1; set fields f = 1; modification made. By rewriting your filters to diagnose that there are no changes rather than arbitrarily setting values to equal values, and by turning off the Modified flag on your trigger field, or by turning off the dirty bit at the end (a new filter that compares the fields you are modifying with the db.fields and if no changes turns off the dirty bit). This would still leave AR_ESCALATOR on those records that really were changed but (presumably) not on all records. Meta-Update by default does not issue the modify when nothing has changed. So certainly you would be able to do this with Meta-Update no problem. You also do not run into the filter limit. Cheers Ben Chernys Senior Software Architect Software Tool House Inc. Canada / Deutschland / Germany Mobile: +49 171 380 2329GMT + 1 + [ DST ] Email: Ben.Chernys _AT_ softwaretoolhouse.com Web: www.softwaretoolhouse.com Check out Software Tool House's free Diary Editor. Meta-Update, our premium ARS Data tool, lets you automate your imports, migrations, in no time at all, without programming, without staging forms, without merge workflow. http://www.softwaretoolhouse.com/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: February-10-12 04:03 To: arslist@ARSLIST.ORG Subject: Re: Escalation trigger filters without modifying records? If your normalization happens on every save of the record then are you having to run thru them on a schedule to update them because something somewhere else changed? i.e. If you are setting a Name field in Form AAA on save, are you trying to keep that Name field in sync with a Name somewhere else (like on Form BBB)? I would look at trying to detect when the source of Name (Form BBB) is changed and force the related records (Form AAA) to update at that time. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle Sent: Thursday, February 09, 2012 6:13 PM To: arslist@ARSLIST.ORG Subject: Escalation trigger filters without modifying records? I've got a lot of filters that do some normalization by setting some key fields via a lookup. This might be a bad idea, but I generally create escalations that do some tidying up-- they just blast through all the records and update a trigger field to trigger the modify filters. Having all the records last modified by AR_ESCALATOR is starting to irritate some of my colleagues, so I'd like to stop doing this. Any thoughts? I've tried several ways to get an escalation to trigger the modify actions without actually modifying the record-- without any success. I also definitely do not want to duplicate the code in the modify actions and copy them into the escalation. Thanks! Brien ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Escalation trigger filters without modifying records?
Editor. Meta-Update, our premium ARS Data tool, lets you automate your imports, migrations, in no time at all, without programming, without staging forms, without merge workflow. http://www.softwaretoolhouse.com/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: February-10-12 04:03 To: arslist@ARSLIST.ORG Subject: Re: Escalation trigger filters without modifying records? If your normalization happens on every save of the record then are you having to run thru them on a schedule to update them because something somewhere else changed? i.e. If you are setting a Name field in Form AAA on save, are you trying to keep that Name field in sync with a Name somewhere else (like on Form BBB)? I would look at trying to detect when the source of Name (Form BBB) is changed and force the related records (Form AAA) to update at that time. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle Sent: Thursday, February 09, 2012 6:13 PM To: arslist@ARSLIST.ORG Subject: Escalation trigger filters without modifying records? I've got a lot of filters that do some normalization by setting some key fields via a lookup. This might be a bad idea, but I generally create escalations that do some tidying up-- they just blast through all the records and update a trigger field to trigger the modify filters. Having all the records last modified by AR_ESCALATOR is starting to irritate some of my colleagues, so I'd like to stop doing this. Any thoughts? I've tried several ways to get an escalation to trigger the modify actions without actually modifying the record-- without any success. I also definitely do not want to duplicate the code in the modify actions and copy them into the escalation. Thanks! Brien ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Escalation trigger filters without modifying records?
Actually, I meant you do the set on problem but also set a display only, change flag inhibited command field. The last filter on modify on problem has a qualification of Command field = my command and (db.firstname = firstname and db.lastname = lastname and and and) That filter then does an Execute Process clean change flag which cancels the update. Turns out that that idea is wrong. The Set-Change-Flag process is only available in Active Links and not in Filters. I guess once the Modify is initiated there's no way to stop it. So, a slight change then more in line with what you are thinking Two DO fields on problem; one to initiate the command, the second to see if the data has changed Set fields from SQL Select count(*) from user form where key = key and firstname = firstname and last name = last name etc The next filter sets the firstname, lastname, etc and has the qual of DO field = 0 Both the DO fields have Disable change flag set. You can still run into filter limits because all transactions under a single escalation are counted together. There is always the use of the Service which if it diagnoses a change could then push to itself. Sorry. I though you could cancel an update but apparently not once the dirty bit is set. Cheers Ben -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle Sent: February-10-12 19:25 To: arslist@ARSLIST.ORG Subject: Re: Escalation trigger filters without modifying records? Thank you all for the feedback. I should have also mentioned that modifying the records for no reason is really at the core of the issue, so the modified by field is a side-issue. Also, normalization versus denormalization-- it is confusing but as far as I understand it you would normally start with normalized data and then add denormalization for performance or, in this case, because that's what AR System encourages. That is my goal, to have a fully normalized data structure with the added denormalized data on top. So I'd like to try to run through what Ben has suggested here on an example, and see if I understand what he's saying. Let's say I have a Problem Ticket form: FirstName LastName UserID(ForeignKey) ProblemInfo And I have a User form with: UserID(PrimaryKey) FirstName LastName So if I follow Ben's suggestion I would add some logic on the Problem Ticket form to diagnose whether the Userinfo has changed instead of just arbitrarily doing a set operation for all records. So I create two display-only fields on Problem Ticket and set Disable Change Flag = True? FirstName LastName UserID ProblemInfo ZTrigger (display only, disable change flag) ZCompare (display only, disable change flag) So my escalation can set ZTrigger = $timestamp$ to trigger the on-modify filters without actually modifying the record? Assuming that is technically possible, then I could have On-Modify filters that do the diagnosis: Do a set-fields ZCompare = Firstname (from User Form). Then another filter w/ qual: If ZCompare != DB.FirstName, set-fields Firstname = ZCompare. Then do the same thing with LastName via a filter guide, I suppose. Fred's suggestion of triggering updates on the source-side (User) actually seems to make the most sense, although David suggests that might be a performance problem. If a single update to a user record has to go update 5,000 records across multiple forms, that might be a problem. Although that could be changed to just run off-peak anyway via an escalation (but now you can't compare DB to TR and so you'd have to store previous values in extra fields, or a set a generic sync flag field? Doh!). I think I must just have a tendency to try to keep workflow self-contained and not creep onto other forms. Actually, that is not the only reason, I just remembered that, quite often, we allow arbitrary input and then we want to link it later. For instance with the Problem Ticket we might take Firstname and Lastname before there is ever a User account, so UserID is NULL. The only way to resolve these is to have an escalation attempt to link it to the User record at a later time (via first and last name). So if Ben's suggestion works, that would be nice to avoid the excessive updates. I'm also thinking of another workflow where a form waits for a record to be created in another system. Right now I have an escalation trigger a modify to perform a check to see if that record has been created yet in a view form, and once it finds a match it moves on to the next task. Again that would be nice to avoid modify updates for just a check. I think I'm done rambling, thank you again I'll post back if I successfully can trigger the on-modify filters via an escalation without actually modifying the records using the tips Ben suggested. Brien On 2/10/2012 8:12 AM, Ben Chernys wrote: What Fred is saying is avoid the escalation by including your normalization at time of save or in his
Re: Escalation trigger filters without modifying records?
Another way I have seen people keep things like this in sync is to use a Join form The New Form Problem Ticket/User Join would Outer Join Problem Ticket and User on ProblemTicket.UserID = User.USerID. It would also have First and Last Name from Problem Ticket and from User. Your Escalation would run against this join where: ProblemTicket.FirstName != User.FirstName OR ProblemTicket.LastName != User.LastName OR ProblemTicket.UserId = $NULL$ On Finding a record that meets the criteria you would Push a flag to ProblemTicket to have it update the fields needed. This is an approach I have used when I am trying to keep User info in sync with an external system (I have a View Form of the External table) Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle Sent: Friday, February 10, 2012 12:25 PM To: arslist@ARSLIST.ORG Subject: Re: Escalation trigger filters without modifying records? Thank you all for the feedback. I should have also mentioned that modifying the records for no reason is really at the core of the issue, so the modified by field is a side-issue. Also, normalization versus denormalization-- it is confusing but as far as I understand it you would normally start with normalized data and then add denormalization for performance or, in this case, because that's what AR System encourages. That is my goal, to have a fully normalized data structure with the added denormalized data on top. So I'd like to try to run through what Ben has suggested here on an example, and see if I understand what he's saying. Let's say I have a Problem Ticket form: FirstName LastName UserID(ForeignKey) ProblemInfo And I have a User form with: UserID(PrimaryKey) FirstName LastName So if I follow Ben's suggestion I would add some logic on the Problem Ticket form to diagnose whether the Userinfo has changed instead of just arbitrarily doing a set operation for all records. So I create two display-only fields on Problem Ticket and set Disable Change Flag = True? FirstName LastName UserID ProblemInfo ZTrigger (display only, disable change flag) ZCompare (display only, disable change flag) So my escalation can set ZTrigger = $timestamp$ to trigger the on-modify filters without actually modifying the record? Assuming that is technically possible, then I could have On-Modify filters that do the diagnosis: Do a set-fields ZCompare = Firstname (from User Form). Then another filter w/ qual: If ZCompare != DB.FirstName, set-fields Firstname = ZCompare. Then do the same thing with LastName via a filter guide, I suppose. Fred's suggestion of triggering updates on the source-side (User) actually seems to make the most sense, although David suggests that might be a performance problem. If a single update to a user record has to go update 5,000 records across multiple forms, that might be a problem. Although that could be changed to just run off-peak anyway via an escalation (but now you can't compare DB to TR and so you'd have to store previous values in extra fields, or a set a generic sync flag field? Doh!). I think I must just have a tendency to try to keep workflow self-contained and not creep onto other forms. Actually, that is not the only reason, I just remembered that, quite often, we allow arbitrary input and then we want to link it later. For instance with the Problem Ticket we might take Firstname and Lastname before there is ever a User account, so UserID is NULL. The only way to resolve these is to have an escalation attempt to link it to the User record at a later time (via first and last name). So if Ben's suggestion works, that would be nice to avoid the excessive updates. I'm also thinking of another workflow where a form waits for a record to be created in another system. Right now I have an escalation trigger a modify to perform a check to see if that record has been created yet in a view form, and once it finds a match it moves on to the next task. Again that would be nice to avoid modify updates for just a check. I think I'm done rambling, thank you again I'll post back if I successfully can trigger the on-modify filters via an escalation without actually modifying the records using the tips Ben suggested. Brien On 2/10/2012 8:12 AM, Ben Chernys wrote: What Fred is saying is avoid the escalation by including your normalization at time of save or in his second case at time of save of another form (with a non AR_ESCALATOR user). (Sorry Fred. Just wanted to make that a bit clearer). The ONLY way to modify a record without changing the fields modifier and modified time is through the Merge API which is not doable by workflow. It is certainly doable with other methods like a Meta-Update script, your own code in a binary etc. ARS always performs the save when fields that set the dirty bit are set - even if they are set to the same
Re: Escalation trigger filters without modifying records?
I like that. Nice and clean. Cheers Ben -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: February-10-12 19:59 To: arslist@ARSLIST.ORG Subject: Re: Escalation trigger filters without modifying records? Another way I have seen people keep things like this in sync is to use a Join form The New Form Problem Ticket/User Join would Outer Join Problem Ticket and User on ProblemTicket.UserID = User.USerID. It would also have First and Last Name from Problem Ticket and from User. Your Escalation would run against this join where: ProblemTicket.FirstName != User.FirstName OR ProblemTicket.LastName != User.LastName OR ProblemTicket.UserId = $NULL$ On Finding a record that meets the criteria you would Push a flag to ProblemTicket to have it update the fields needed. This is an approach I have used when I am trying to keep User info in sync with an external system (I have a View Form of the External table) Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle Sent: Friday, February 10, 2012 12:25 PM To: arslist@ARSLIST.ORG Subject: Re: Escalation trigger filters without modifying records? Thank you all for the feedback. I should have also mentioned that modifying the records for no reason is really at the core of the issue, so the modified by field is a side-issue. Also, normalization versus denormalization-- it is confusing but as far as I understand it you would normally start with normalized data and then add denormalization for performance or, in this case, because that's what AR System encourages. That is my goal, to have a fully normalized data structure with the added denormalized data on top. So I'd like to try to run through what Ben has suggested here on an example, and see if I understand what he's saying. Let's say I have a Problem Ticket form: FirstName LastName UserID(ForeignKey) ProblemInfo And I have a User form with: UserID(PrimaryKey) FirstName LastName So if I follow Ben's suggestion I would add some logic on the Problem Ticket form to diagnose whether the Userinfo has changed instead of just arbitrarily doing a set operation for all records. So I create two display-only fields on Problem Ticket and set Disable Change Flag = True? FirstName LastName UserID ProblemInfo ZTrigger (display only, disable change flag) ZCompare (display only, disable change flag) So my escalation can set ZTrigger = $timestamp$ to trigger the on-modify filters without actually modifying the record? Assuming that is technically possible, then I could have On-Modify filters that do the diagnosis: Do a set-fields ZCompare = Firstname (from User Form). Then another filter w/ qual: If ZCompare != DB.FirstName, set-fields Firstname = ZCompare. Then do the same thing with LastName via a filter guide, I suppose. Fred's suggestion of triggering updates on the source-side (User) actually seems to make the most sense, although David suggests that might be a performance problem. If a single update to a user record has to go update 5,000 records across multiple forms, that might be a problem. Although that could be changed to just run off-peak anyway via an escalation (but now you can't compare DB to TR and so you'd have to store previous values in extra fields, or a set a generic sync flag field? Doh!). I think I must just have a tendency to try to keep workflow self-contained and not creep onto other forms. Actually, that is not the only reason, I just remembered that, quite often, we allow arbitrary input and then we want to link it later. For instance with the Problem Ticket we might take Firstname and Lastname before there is ever a User account, so UserID is NULL. The only way to resolve these is to have an escalation attempt to link it to the User record at a later time (via first and last name). So if Ben's suggestion works, that would be nice to avoid the excessive updates. I'm also thinking of another workflow where a form waits for a record to be created in another system. Right now I have an escalation trigger a modify to perform a check to see if that record has been created yet in a view form, and once it finds a match it moves on to the next task. Again that would be nice to avoid modify updates for just a check. I think I'm done rambling, thank you again I'll post back if I successfully can trigger the on-modify filters via an escalation without actually modifying the records using the tips Ben suggested. Brien On 2/10/2012 8:12 AM, Ben Chernys wrote: What Fred is saying is avoid the escalation by including your normalization at time of save or in his second case at time of save of another form (with a non AR_ESCALATOR user). (Sorry Fred. Just wanted to make that a bit clearer). The ONLY way to modify a record without changing the fields modifier and modified time is through
Re: Escalation trigger filters without modifying records?
Hmm, yeah this is pretty clean, and allows you to do the diagnosis via the (passive) join instead of via the filter madness. Seems like there are several tradeoffs with any approach, be it performance or simply added complexity. I was really hoping to keep *all* the complexity within an on-modify filter and then just trigger that when modified and periodically (two birds, one stone). Oh well, we don't always get exactly what we want. Thanks for your help!! Brien On 2/10/2012 12:45 PM, Ben Chernys wrote: I like that. Nice and clean. Cheers Ben -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: February-10-12 19:59 To: arslist@ARSLIST.ORG Subject: Re: Escalation trigger filters without modifying records? Another way I have seen people keep things like this in sync is to use a Join form The New Form Problem Ticket/User Join would Outer Join Problem Ticket and User on ProblemTicket.UserID = User.USerID. It would also have First and Last Name from Problem Ticket and from User. Your Escalation would run against this join where: ProblemTicket.FirstName != User.FirstName OR ProblemTicket.LastName != User.LastName OR ProblemTicket.UserId = $NULL$ On Finding a record that meets the criteria you would Push a flag to ProblemTicket to have it update the fields needed. This is an approach I have used when I am trying to keep User info in sync with an external system (I have a View Form of the External table) Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle Sent: Friday, February 10, 2012 12:25 PM To: arslist@ARSLIST.ORG Subject: Re: Escalation trigger filters without modifying records? Thank you all for the feedback. I should have also mentioned that modifying the records for no reason is really at the core of the issue, so the modified by field is a side-issue. Also, normalization versus denormalization-- it is confusing but as far as I understand it you would normally start with normalized data and then add denormalization for performance or, in this case, because that's what AR System encourages. That is my goal, to have a fully normalized data structure with the added denormalized data on top. So I'd like to try to run through what Ben has suggested here on an example, and see if I understand what he's saying. Let's say I have a Problem Ticket form: FirstName LastName UserID(ForeignKey) ProblemInfo And I have a User form with: UserID(PrimaryKey) FirstName LastName So if I follow Ben's suggestion I would add some logic on the Problem Ticket form to diagnose whether the Userinfo has changed instead of just arbitrarily doing a set operation for all records. So I create two display-only fields on Problem Ticket and set Disable Change Flag = True? FirstName LastName UserID ProblemInfo ZTrigger (display only, disable change flag) ZCompare (display only, disable change flag) So my escalation can set ZTrigger = $timestamp$ to trigger the on-modify filters without actually modifying the record? Assuming that is technically possible, then I could have On-Modify filters that do the diagnosis: Do a set-fields ZCompare = Firstname (from User Form). Then another filter w/ qual: If ZCompare != DB.FirstName, set-fields Firstname = ZCompare. Then do the same thing with LastName via a filter guide, I suppose. Fred's suggestion of triggering updates on the source-side (User) actually seems to make the most sense, although David suggests that might be a performance problem. If a single update to a user record has to go update 5,000 records across multiple forms, that might be a problem. Although that could be changed to just run off-peak anyway via an escalation (but now you can't compare DB to TR and so you'd have to store previous values in extra fields, or a set a generic sync flag field? Doh!). I think I must just have a tendency to try to keep workflow self-contained and not creep onto other forms. Actually, that is not the only reason, I just remembered that, quite often, we allow arbitrary input and then we want to link it later. For instance with the Problem Ticket we might take Firstname and Lastname before there is ever a User account, so UserID is NULL. The only way to resolve these is to have an escalation attempt to link it to the User record at a later time (via first and last name). So if Ben's suggestion works, that would be nice to avoid the excessive updates. I'm also thinking of another workflow where a form waits for a record to be created in another system. Right now I have an escalation trigger a modify to perform a check to see if that record has been created yet in a view form, and once it finds a match it moves on to the next task. Again that would be nice to avoid modify updates for just a check. I think I'm done rambling, thank you again I'll post back if I successfully
Escalation trigger filters without modifying records?
I've got a lot of filters that do some normalization by setting some key fields via a lookup. This might be a bad idea, but I generally create escalations that do some tidying up-- they just blast through all the records and update a trigger field to trigger the modify filters. Having all the records last modified by AR_ESCALATOR is starting to irritate some of my colleagues, so I'd like to stop doing this. Any thoughts? I've tried several ways to get an escalation to trigger the modify actions without actually modifying the record-- without any success. I also definitely do not want to duplicate the code in the modify actions and copy them into the escalation. Thanks! Brien ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Escalation trigger filters without modifying records?
If your normalization happens on every save of the record then are you having to run thru them on a schedule to update them because something somewhere else changed? i.e. If you are setting a Name field in Form AAA on save, are you trying to keep that Name field in sync with a Name somewhere else (like on Form BBB)? I would look at trying to detect when the source of Name (Form BBB) is changed and force the related records (Form AAA) to update at that time. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle Sent: Thursday, February 09, 2012 6:13 PM To: arslist@ARSLIST.ORG Subject: Escalation trigger filters without modifying records? I've got a lot of filters that do some normalization by setting some key fields via a lookup. This might be a bad idea, but I generally create escalations that do some tidying up-- they just blast through all the records and update a trigger field to trigger the modify filters. Having all the records last modified by AR_ESCALATOR is starting to irritate some of my colleagues, so I'd like to stop doing this. Any thoughts? I've tried several ways to get an escalation to trigger the modify actions without actually modifying the record-- without any success. I also definitely do not want to duplicate the code in the modify actions and copy them into the escalation. Thanks! Brien ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
