Calculated Fields Documentation

[seberly]

I haven't found any formal documentation on the wiki about calculated fields. Could someone please direct me to an article that I missing or are the plans to create an article for this?

Thanks,
Scott

[CapaJ]

@Brunno Santos I think calculated fields are still the devil encoded. If one of them only relies on other values in the same record, that should be even easier to maintain with a Business Rule instead.

Another recent example that cost a customer, Support and me too much time: a dotwalked calculated field in a list does not get its value calculated fresh on list render, so you can see a different value in the list vs. the form when you drill in. This is due to a rather important bit of performance optimization done for lists, turns out. Combined with an ill-advised i18n customization the admin had no way of knowing might be problematic, it was a bit of a mess to untangle if you didn't already know what was happening and why.

[samurai2]

@CapaJ I created a calculated field, and I have an issue that when updating the value, it is updated in the list(U16), but in the database view, it keeps the old one

[Jason Siegrist]

I do not even see them on the platform anymore.   Btw I have personally broken whole SN platforms by trying to use Calculated Fields. 

[tim2222]

As this turns up in Google results for calculated fields. HRSD's sn_hr_core_job.job_active field is a calculated field:

(function calculatedFieldValue(current) { return (gs.nil(current.job_end_date) || current.job_end_date >= new GlideDate().getValue()) && (!gs.nil(current.job_start_date) && current.job_start_date <= new GlideDate().getValue()); })(current);

Which, if you set a future end date on a job, that dates comes and job_active will not be updated (because calculated fields are only written on update, even if they look ok on view?).

[CapaJ]

Yup. DB value of a calculated field can often be different than what's shown in a list or form - at least until the next time the record is updated.

I suppose an enhancement to that app might create/maintain a job in the scheduler that runs on one or both of those dates to force-update the record, so queries on that Boolean would work as expected. Might not be worth the effort, I don't know.