- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-24-2024 05:12 PM
Solved! Go to Solution.
- Labels:
-
Architect

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-26-2024 03:57 AM
Using a script for this rather than out-of-box functionality is not recommended. I would recommend you configure your SLAs as follows:
Table | Start condition | User-specified duration | Schedule |
incident | Priority = 1 | 1 hour | <your schedule> |
incident | Priority = 2 | 8 hours | <your schedule> |
incident | Priority = 3 | 1 day | <your schedule> |
incident | Priority = 4 | 2 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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-25-2024 05:54 AM
I am trying to do it as POC for my org, I will update you more about it once it works as expected.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-26-2024 04:16 AM
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]
****************************************************************************************************************
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-26-2024 12:21 AM
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-26-2024 03:57 AM
Using a script for this rather than out-of-box functionality is not recommended. I would recommend you configure your SLAs as follows:
Table | Start condition | User-specified duration | Schedule |
incident | Priority = 1 | 1 hour | <your schedule> |
incident | Priority = 2 | 8 hours | <your schedule> |
incident | Priority = 3 | 1 day | <your schedule> |
incident | Priority = 4 | 2 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!