Hi Rod, That is indeed the approach I'm taking. All the dirty work happens in filters that get triggered based on setting a display only field on Form B. The catch is that I need to mark existing records in Form A as being ready to process, and then mark any that didn't get processed as not having been processed, because they didn't match an existing configuration. It _looks_ like filter phasing may be causing an issue where not all of the records in step 2 get processed before step 3 gets executed, causing some records to get erroneously marked has not matching a configuration.
I know that it would be ideal to simply touch and process each record in Form A without having to do the multistep process. However, I'm trying to efficiently process records based on a dynamic qualification specified in form B. That is, Form B contains configuration data that includes a Remedy qualification that I can test to see if a record in Form A pertains to that configuration. It seems to me that if I want to process everything from the perspective of the record in Form A, I would need to test it against each configuration record in Form B to see which one it matches, and then process it accordingly. If it doesn't match one, then I could simply change the status to indicate that and move on. However, that feels very inefficient, because on average, I would have to query Form B ½*n times for every record in Form A, where "n" is the number of entries in Form B. To work around that, I am processing the records from the perspective of Form B. I simply added a table to the form that include the qualification stored in the form (using EXTNERAL($field$)). Now, in one query, I can see all the records in Form A that that correspond to that Record in Form B. Then I simply need to iterate over the table and process all the records. I do this for all records in Form B, and that effectively processes all matching records in Form A. Any records left unprocessed in Form A didn't match a configuration and can be tagged as such. Does that make sense? It's a bit round about, but, overall, processing things this way made the workflow a bit easier to write and I think should execute more efficiently. The only catch is that I need to ensure that all the records that can get processed do before I try to tag the ones that didn't. I have seen a case where several records that did match a configuration got tagged as not matching, and I believe that was due to filter phasing. If adding the `! to an escalation has the same effect that is has to a filter, then I think I should be OK. Thanks, Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rod Harris Sent: Tuesday, May 05, 2009 3:15 AM To: arslist@ARSLIST.ORG Subject: Re: Filter Phasing and Escalations ** Hi Lyle, Do you really need to override the phasing etc in the escalation itself? There is normally no need to do a lot of workflow in the escalation. It is common to use the escalation to merely trigger workflow in filters that do the actual work. You can do all the overriding of phases etc in the filters. The other benefit of putting the workflow in filters is that it runs all the time regardless of trigger and you don't need to replicate the same logic for both events (a manual update or an escalation triggered update) Rod 2009/5/5 Lyle Taylor <tayl...@ldschurch.org<mailto:tayl...@ldschurch.org>> ** Let me clarify a bit. The documentation states that you can add the Run Process action Application-Release-Pending between each of the actions to get what I'm looking for and mentions that it can be used in escalations. However, since it normally runs in phase 3, you have to use the special filter naming convention to override filter phasing for it to be applied properly between the push fields actions. I guess my question boils down to this: do filter phases apply in escalations, and if they do, can you add `! to the escalation name to override phasing just like you do with filters? Thanks, Lyle From: Lyle Taylor Sent: Monday, May 04, 2009 4:05 PM To: 'arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>' Subject: Filter Phasing and Escalations Hi All, Can anyone tell me if filter phasing applies to escalations? I have a three-step process involving two forms, and I need to guarantee that certain actions happen in a specific order. I'm also trying to process records in batches, so I have an escalation that does something like this: 1. Set the status of all records in Form A to "Process" 2. Set the field "Process Now" in Form B 3. Set the status of all records in Form A whose status is still "Process" to "No Configuration Matched" Basically, Form A contains records to be processed, and new records can be added to it at any time. Form B contains configurations that map back to zero or more records in Form A. At intervals, I set the status of all new records in Form A to Process. Then I trigger the processing of those records from Form B by setting a field that triggers the processing workflow. As part of that, the status of all records that got processed get set to a status that indicates they have been processed. I then want to set the status of any remaining records that were tagged for processing but that didn't match any configurations in Form B to "No Configuration Matched". So, the question is, how can I guarantee that all records get processed in action 1 before action 2 gets processed, and that all records affected by processing related to action 2 (including affected records in Form A) get processed before action 3 fires? Does that make sense? Thanks, Lyle NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _Platinum Sponsor: rmisoluti...@verizon.net<mailto:rmisoluti...@verizon.net> ARSlist: "Where the Answers Are"_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
