(10 votes, average: 4.20 out of 5)
Loading ...As we all know that On Field Update Set user property is used to set value of a field when another field is updated. But few days back I discovered a drawback while using this user property.
Requirement:
If Field “Product Family” has value “Aircraft” then value of field “Contract Value” should be set as “Cust-Yahoo” otherwise the field value should be “Cust-Google”.
Solution:
It seemed simple enough I went ahead and created a On Field Update Set property with following value:
“Product Family”, “Contract Value”, “IIf ([Product Family] = “”Aircraft”", “”Cust-Yahoo”", “”Cust-Google”")”
I tested the solution and it was working fine. But then I notices one thing
Problem:
Product Family field had a Pre-Default Value assigned to it so, when I created a new record for Quote this user property didn’t take effect. Then I realized that, this user property only gets triggered when user manually updates a field.
If the value of field is being set through a PickMap, Pre-Default or Post-Default value then this user property doesn’t get triggered.
Alternate Solution:
I thought of doing it through scripting but decided against it and used expression in Pre-Default value of that field which was as following
Expr: “IIf([Product Family]= ‘Aircraft’ ,’Cust-Yahoo’, ‘Cust-Google’)”
and this solution worked fine in all scenarios.
Authors bio is coming up shortly.
Loading ...
I don’t agree with you Neel.
Predefault is something like “substitution” of PreNewRecord event. And in that way, On Field Update Set is substitution of SetFieldValue event. So, PreDefault and PostDefault Properties should not trigger the On Field Update Set.
And if you change your field by pickmap, that will trigger that user property.
I think you got it wrong.
Post and Pre-Default properties don’t trigger on “On Field Update Set” but it’s vice versa which means On Field Update doesn’t trigger when the value to a field is assigned via Pre or Post Default properties.
I hope this clears the confusion
I dont think, this was an effective solution.
Example :- If [Product Family]=”Aircraft” , Contract Value automaticlly becomes “Cust-Yahoo” This will work fine only while creating the record i.e at time of New Record Event. Lets suppose above has happened and now user changes the Value of [Product Family] to “Non Aircraft” , Now your Contract Value wont change to “Cust-Google”.
Also, for above expression to work, [Product Family] field should be set first by Siebel automatically and after that [Contact Value]. I guess you cant do any sequencing for setting field value. So may be in your case, you are lucky to get this sequence automatically.
you just have to set manually the predefault of your “Product Family” Field … there is no point in making it dynamic …
OK,
the behaviour cited is clearly an intended behaviour.
So, your ignorance of this cannot be a drawback of the product itself.
When you have not committed a record to the database yet, why would siebel treat it as an update?
On a pickmap, you are the primary field on the pickmap will have the change trapped.
Same goes for an Update from UI.. changing field value from UI doesn’t mean that record is commited to database .. user still has option to undo the changes…
So, it doesn’t have to do anything with record being commited to database and I am not sure what you mean when you say
I agree with you neel thanks for clarification.