Thanks so much everyone! Luckily I did not cause too much damage. It sounds so elementary, but it caught me by surprise! I ended up creating a separate Filter just to make things easier for me to control. And I have a Run If on my Merge Filter to make sure that it only runs when the record is brand new (a.k.a. submit).
Lisa ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mueller, Doug Sent: Friday, April 16, 2010 3:58 PM To: [email protected] Subject: Re: Merge Workflow ** Lisa, Merge is something that can do a create or can do a set. It depends on whether there is a record in place or not. That is correct. Be careful using the Submit filter as you describe because that will fire on Submit as well as Merge which may or may not be right because you may or may not actually want the same thing happening. So, what to do.... Well, we have just been discussing DB and TR.... If you put a qualifier on the filter of 'DB.Entry ID' = $NULL$, you will know the difference. If it is TRUE, there is no existing record so you are creating a new one during Merge. If it is FALSE, there is an existing record so you are updating the record. Entry ID is ALWAYS present in any record so there are no error cases. Now, it turns out that On Submit, 'DB.Entry ID' = $NULL$ as well. So, if you really did want identical logic to run when you Submit an entry and when you Merge and it creates a new entry (vs. updates one), you can select both the Submit and Merge firing condition, put the run If to 'DB.Entry ID' = $NULL$ and go with one filter. HOWEVER, you do need to be careful that you don't have an ELSE action. If you do, you have to use separate filters for Submit and Merge or you will get bad behaviour. If you have additional run if criteria, not a problem just AND and the clause above with the entire preceding qualifier in parenthesis to make sure it all holds together. But the else action is a problem if present. Anyway, my suggestion is it is best not to tempt fate and cause complexity and to keep Submit and Merge filters separate. Typically you do want different logic to run on them (not always, but often). If you want to differentiate between create and set happening during merge, the 'DB.Entry ID' = $NULL$ (or != for the set test) is the answer. Doug Mueller ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Kemes, Lisa Sent: Friday, April 16, 2010 9:36 AM To: [email protected] Subject: Merge Workflow ** I have a Filter that sets a field on Submit. I have another Filter that sets the same field (with slightly different data) on Modify. I made the mistake of adding Merge to my Submit Filter, thinking (foolishly) that it would only do what I needed it to do if the Merge was a "submit" or new record. Well it did what I wanted the Submit Filter to do even though my Merge was updating records. I know how to fix this (make a separate Merge Filter) but does this happen to anyone else? A Merge is a Merge I guess whether you are creating a new record or updating.... Lisa Kemes AR System Developer Tyco Electronics 717-810-2408 tel 717-810-2124 fax [email protected] _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
