SLA on RITM due date

[Russell Abbott]

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

[Russell Abbott]

Absolutely. Edit: We are using Flow Designer too. I think that may impact where the Delivery Time value comes from.

Default SLA flow OOTB

I do see that the 'delivery time' is 0

Although i do have a number of days set on this particular catalog item here

Due date on the RITM

[Allen Andreas · Accepted solution]

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:

1. 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:
   
2. 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.
3. 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!

[Russell Abbott]

This is exactly what i see. Due date being set twice.

#1 may not work because it's a Reusable flow for many Catalog Items

#2 may work, but I'd need to make sure it takes into account the schedule for exclusion of holidays and weekends

[Allen Andreas]

Hi,

Understood. That'll be something you'll have to think through and decide your approach that works in a scalable way.

I'm glad I could help uncover more regarding all this.

If you don't mind, if any reply of mine thus far through this thread has also been Helpful, please mark as Helpful.

Thanks! 🙂