SLA on RITM due date

Russell Abbott · ‎01-20-2022

I created an SLA for a RITM and selected 'Breach on Due Date', but through testing i discover that you're only able to base this on the due date of the task and not the due date of the RITM itself.

I have many RITM's that generate multiple tasks, the due dates of those tasks are seperate from the due date of the RITM as a whole.

So, instead of using just one SLA and the expected delivery time/due date, i have to create many SLA's to manage the different expectations of our whole RITM catalog.

Has anyone managed to implement anything similar to what i'm looking for?

Thanks

Allen Andreas · ‎01-20-2022

Hi,

Thanks for providing all that.

So the delivery time specified on the catalog item will only be used when there isn't a workflow/flow/execution plan already specified. If one of those is specified, it'll use that, instead.

With what you've shown above, if you navigate to that request item record and use the context menu and go to: History > List, you may see that the due date field is being set twice. Once, for the same date/time as when it was ordered, then, later updated to another value which I assume is a script or something setting this (script in the workflow or perhaps a business rule on the sc_req_item table, etc.).

So you have a few options:

Define the delivery time accordingly in the flow for this catalog item to make sure it's set to 25 days there, see screenshot for example of where to go to set that on the flow:
Change your SLA to only start when the record is ready to have it's SLA start. So you may need to set a condition beyond just active is true, and use active is true AND 'x' AND 'y' for it to correctly start after your RITM due date field is "properly" set.
Create a custom relative duration script that takes the current date/time and adds 'x' number of days per the catalog item field and the specified delivery time there (I assume this may be what your script (if you're setting the due date via script in the first place) is doing anyway), so you'd add that same behavior to the script

Please mark reply as Helpful, if applicable. Thanks!

Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

View solution in original post

Allen Andreas · ‎01-20-2022

Hi,

You can create a relative duration to use the current record's (which this would be on the RITM table) and it's due date to calculate the SLA breach date: https://docs.servicenow.com/bundle/rome-platform-administration/page/administer/time/task/t_DefineAR...

Please mark reply as Helpful/Correct, if applicable. Thanks!

Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

Russell Abbott · ‎01-20-2022

I hadn't seen this. Thanks for the reply. Ill take a look at this. I think SN could make it a little more intuitive but i think this should definitely help. Thanks!

Russell Abbott · ‎01-20-2022

I do see a relative duration script here already, which gets the due_date from the current table (which is the task table). How can i edit that to tell it to get the due_date from the sc_req_item table instead?

var tableName = current.getTableName();
  if (tableName) {
       var baseTableName = GlideDBObjectManager.getAbsoluteBase(tableName);
       if (baseTableName == "task")
            dueDate = current.getElement("due_date");
       else if (baseTableName == "task_sla")
            dueDate = current.getElement("task.due_date");
  }

Allen Andreas · ‎01-20-2022

Hi,

So this would get it get it if the table extended from the task table as it's core base, which sc_req_item is.

So in the SLA definition, did you choose relative due date based on and choose "SLA record" and not "task record"?

Please mark reply as Helpful/Correct, if applicable. Thanks!

Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!