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

Russell Abbott · ‎01-20-2022

I tried both settings. Task and SLA. But each time, the SLA breaches within one second. I went into the SLA workflow and added the Schedule there also, but it still breach after 1 second.

Allen Andreas · ‎01-20-2022

Hi,

Just to clarify, I have my SLA definition example set such as:

Ordered a catalog item with the delivery date listed in the item as you're preparing to order like this:

Which resulted in a due date like this:

And the task SLA such as:

Does your request item you're testing with have the same day as the due date or is it a future date (like mine)?

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 see, i may have to look at the SLA flow, mine is set up the same as yours. The due date does indeed show in the future correctly. I appreciate the screenshots and information!

Russell Abbott · ‎01-20-2022

I created a test SLA the same as in your screenshots, with the Default SLA flow also and it still would breach after one second.

Allen Andreas · ‎01-20-2022

Hi,

Can you share your screenshots, similar to mine?

Just so I can see your settings and the due date on the RITM, etc.

Are you sure the RITM is being set with a due date by the flow/workflow on the catalog item? Or is the due date being set through some sort of script or business rule within your instance?

If it's not being set through the flow, naturally, like how I showed the catalog item delivery estimate, then it sounds like the SLA is breaching because there is no due date in the record for a split moment, if that makes sense.

Please mark reply as Helpful, if applicable. Thanks!

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