ServiceNow script for calculating the due date of an incident based on its priority.

dmarpaka
Tera Contributor
I tried writing a before insert BR and calculate the due date by adding created date and based on the priority of the incident. I am getting a compilation error, can someone help me achieve this
 
(function executeRule(current, previous /*null when async*/ ) {

    // Check if the incident is being created
    if (current.operation() == 'insert') {

        // Get the incident created date
        var createdDate = new GlideDateTime(current.getValue('sys_created_on'));

        // Get the priority of the incident
        var priority = current.getValue('priority');

        // Calculate SLA duration based on priority
        var slaDuration;
        if (priority == '1') {
            slaDuration = new GlideDuration('0 01:00:00'); // Priority 1 gets 1 hour SLA time
        } else if (priority == '2') {
            slaDuration = new GlideDuration('0 08:00:00'); // Priority 2 gets 8 hours SLA time
        } else if (priority == '3') {
            slaDuration = new GlideDuration('1 00:00:00'); // Priority 3 gets 1 day SLA time
        } else if (priority == '4') {
            slaDuration = new GlideDuration('2 00:00:00'); // Priority 4 gets 2 days SLA time
        }

        // Add SLA duration to created date

        var schedule = new GlideSchedule('08fcd0830a0a0b2600079f56b1adb9ae');
        var dueDate = schedule.add(createdDate, slaDuration);
        current.u_due_date = dueDate;
    }

})(current, previous);
1 ACCEPTED SOLUTION

Ryan Duce
Tera Guru

Using a script for this rather than out-of-box functionality is not recommended. I would recommend you configure your SLAs as follows:

 

TableStart conditionUser-specified durationSchedule
incidentPriority = 11 hour<your schedule>
incidentPriority = 28 hours<your schedule>
incidentPriority = 31 day<your schedule>
incidentPriority = 42 days <your schedule>

 

Then, you should build a report on the out-of-box incident_sla table, which joins the incident table with the task_sla table and includes the "Breach time" field from the generated task_sla record, which is automatically populated with the due date you're looking for.

 

Benefits of this approach

  • No custom code which must be tested after each upgrade
  • No hard-coded sys-ids or durations - easy to reconfigure the timings of the SLAs
  • No custom fields
  • Additional SLAs can easily be added at a later date - the solution is far more scalable

Please mark as correct or helpful if this assisted you!

View solution in original post

8 REPLIES 8

I am trying to do it as POC for my org, I will update you more about it once it works as expected.

Thanks @dmarpaka for update. If possible go OOTB and use SLA for this.

*************************************************************************************************************
If my response proves useful, please indicate its helpfulness by selecting " Accept as Solution" and " Helpful." This action benefits both the community and me.

Regards
Dr. Atul G. - Learn N Grow Together
ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
Topmate: https://topmate.io/atul_grover_lng [ Connect for 1-1 Session]

****************************************************************************************************************

ashishdevsingh
Tera Expert

Can you please check in log what exactly you are getting in error ?
i would suggest you to please use current date time instead of sys_created_on. Reason: since you are using the before BR and calculating the value based on sys_created_on. So i am not sure if till that time you get the created_on value correctly. It depends on DB operation execution. 

Instead of that, run this BR after and trigger the event which calculate the due date value using same code and update the record. 

Ryan Duce
Tera Guru

Using a script for this rather than out-of-box functionality is not recommended. I would recommend you configure your SLAs as follows:

 

TableStart conditionUser-specified durationSchedule
incidentPriority = 11 hour<your schedule>
incidentPriority = 28 hours<your schedule>
incidentPriority = 31 day<your schedule>
incidentPriority = 42 days <your schedule>

 

Then, you should build a report on the out-of-box incident_sla table, which joins the incident table with the task_sla table and includes the "Breach time" field from the generated task_sla record, which is automatically populated with the due date you're looking for.

 

Benefits of this approach

  • No custom code which must be tested after each upgrade
  • No hard-coded sys-ids or durations - easy to reconfigure the timings of the SLAs
  • No custom fields
  • Additional SLAs can easily be added at a later date - the solution is far more scalable

Please mark as correct or helpful if this assisted you!