Creating a business rule on a custom table to calculate the difference between the opened_at and closed_at field using the "dateDiff" method is not working as it should. The results that should show into the duration-type fields are not entered, resulting in an empty field.

This is not an issue with OOB tables that extend Task (such as Incident, Problem, ect.), but only custom made tables extending Task.

Ref. "dateDiff" method explanation as it should populate a duration-type field:

Set a duration field value


Steps to Reproduce

1. Create a table that extends Task.
2. In the form design, add the "Opened (opened_at)", "Closed (closed_at)" and "Duration (calendar_duration)" fields.

Enterprise instances only:

3. Create a "before" (or "after") business rule with the new table loaded in the "Table" field, and set to "Active".
4. Enter the following in the "Script" field of the business rule:
function onBefore(current, previous) {
   //This function will be automatically called when this rule is processed.
current.calendar_duration = gs.dateDiff(current.opened_at.getDisplayValue(),current.closed_at.getDisplayValue(),false);

Express instances do not offer scripting features, so the custom table won't have any business rule populating the duration fields.

5. Test by opening a new record and saving it. Notice that the "Opened" field is populated.
6. Now set the state of the new record to "Closed". Notice that the "Closed" field is populated but the "Duration" field still displays empty.

In order to see how it should work, add the "Opened (opened_at)", "Closed (closed_at)" and "Duration (calendar_duration)" fields to the "Incident" form. Repeat the same test on an incident form records following steps 5 and 6 above. Notice that the "Duration" field is now populated with a value.



This behaviour is due to the order of execution within the record update flow. It may occur because the closed_at field is not yet populated when the custom business rule on the extended table is executed. In case the business rule is set to run After Update, it would be needed to update the record once more after its closure, like entering a final work note. The duration field should then get populated. This issue should not occur if the business rule is set to run Before Update. It is anyway best practice to give a low order of execution to the business rule, so to avoid the expected duration update to be overridden by other business rules running earlier.



This is a limitation in the current release, as no scripted business rule can be created as a workaround. The migration to the new ITSM platform will overcome this limitation.


The related issue on the wrong business duration calculation returning 0" is fixed in Istanbul Patch 7 on all platforms.

Ref. PRB680207 - The base system business rules 'mark_closed' and 'mark_resolved' use deprecated calendars and return incorrect results

Related Problem: PRB702360

Seen In

Fuji Patch 13 Hot Fix 1

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2018-02-05 10:18:10