Barry~

In answer to your questions:

1) Yes, placing evaluateFormulaFields near the end of the createRow process was intentional. This to allow formulas that depend on values in the same row to be able to evaluate. 

2) Based on the above response, its better to call evaluateFormulaFields at the end.

Thanks!
Karen

Barry~

I am changing this to an idea under consideration for our devs to consider … Vote this issue up if you agree with Barry!

Thanks!
Karen

Hi Karen -

Thanks for the reply and info and changing this to an idea!

If my understanding of how formulas works is correct, if the formulas are moved to earlier in the process, the following would occur:

1) Formula fires that relies on field value in same row - since there is no value yet, the formula would just use null/empty behavior.  No harm done here.
2) Other field gets updated on same row - this will end up calling UpdateRow which will, in turn, call evaluateFormulas which will then result in formula field evaluating again, this time on the value from the field that was just updated.  

Changing to this approach would yield the following benefits:

1) Formula fields would always have a value
2) Formula fields could be used in establishing defaults, etc.

I’d have to spend some time really thinking this through some more and reviewing code but I don’t think this would introduce any performance impact since it’s just moving code that is already getting called to another location in the process. If there is a performance impact, I think it would be negligible and performance is the only potential downside that I could see to making this change.  If this change were made, it should be completely transparent to everything but with the benefits listed above.

Thanks!

bump