David, First obvious question... What changed? Did anything change about the form defintion or the workflow on the form?
There is a fairly good picture of how Filters work on Join forms in the BasicGuide-630.pdf at page 189. But to try to briefly explain it... ( It covers 5 data forms joined together with 4 Join forms. ) I will use an example using their naming schema so that you can use that picture to follow my logic below. :) It is my understanding that the order of the workflow firing (and which forms the workflow first on) is dependent on the fields that are updated in the join. In your case you said that you have three forms involved. So lets say this is the structures: Form A(primary) joined with Form B -->(makes) Join Form F Join Form F(primary) joined with Form C -->(makes) Join Form H (That is three forms in my book. maybe you only ment two forms, but the rest should still make sense if that is the case.) So the user Modifies Form H in some way. That means that filters on Form H will fire for "Modify". (That should always happen.) Now if the user also modified a field that was part of Form F ( a field from: Form F (Display only), or Form A or Form B) then the Modify Filters on Form F would be processed. If any of the the fields on Form F were from Form A then the Modify Filters on Form A would be processed. If any of the the fields on Form F was from Form B then the Modify Filters on Form B would be processed. Lastly.... If any of the the fields on Form C were modified then the Modfy Filters on Form C would fire. So the "trick" should be that the modification that the user does should not trigger any fields to be altered that would affect the "wrong form(s)". I am afraid without more specifc details it will be hard to make any other suggestions. But if you track the workflow I think you will find the order of the filters to be what is above and you should be able to see what fields are being altered by what workflow. As a tip that might be of some help.... As a "debug idea".... add a filter with a notification action to all of the forms of interest. Have the notification action send an email to an Administrator account (by username) with the "Changed fields" included in the notification and include the $ SCHEMA $ value in the notificaiton text too. That should also give you a good idea of what fields are being altered in the workflow. HTH. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 2/28/07, David Yearsley <[EMAIL PROTECTED]> wrote:
** We have been using Remedy Purchasing for several months and need help with a problem we have been unable to fix. We have an open ticket with BMC, but we are hoping for some enlightenment for the list. In Remedy Purchasing an approver should be able to approve a request without an Asset license. When we first started the programming this was working, now we are having to assign a floating license to approve. While working with remedy we have identified where the problem is occurring but not why it is occurring. The approval takes place on a join of three forms. One of the forms is AST:PurshaseRequisistion. This form is not suppose to update when you do a commit on the Join. For some reason this is now the first form that is being updated. Does anyone have any ideas on what changes would cause this form to suddenly save (set) when it wasn't in the past? Thanks
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
