SLA: how to define a retroactive stop date?

[Aka Guglielmo]

Do you know if it's possible to define a retroactive stop date in sla definition?

Any idea or help is appreciated.

Thanks,

WLY

[Uncle Rob]

The real trick is accomplishing it in such a way that doesn't give the same users a back door to modify their SLA numbers.

[Goran WitchDoc]

Well, if you want to measure the time between create date and end of work, you can just take those two dates and calculate the "business time" with a schedule. then you can get for example average time etc.

But as Robert posts.. The big thing here is make sure they don't put a end of work date that isn't correct just to make the numbers look good.

[Uncle Rob]

It does kind of point to a weakness with our form-based tracking / workflow tools.   We need some seriously low-friction interfaces.

The idea that "I can't update my changes because I'm doing changes" isn't a function of vendor/worker laziness, but rather that our UX's really are primitive.  

We have the tech... we just need a UX smooth enough that we can make the start and stop of a Change part of the procedure of executing one.   Pull up your phone, click the change, click the ENORMOUS start button.   Then click the ENORMOUS stop button when done.   For a total of 30 seconds added transaction time for every ticket.

One can dream anyway

[pavel_martinec]

Hi, I am in need for this specific feature. This article is way too old, but I think there was no progress on this during the years?

My use case:
We are PULLING data from a 3rd party tool. The interval is let's say 5 minutes. But we need a very accurate SLA reporting due to possible contractual breaches.

I will receive a payload with like state:new, time:1.1.2025 10:00.
But due to the pull delay, I will receive that payload at 10:05. This is OK, because i can do retroactive start.
But the similar thing will happen with the end. I receive payload state:new, time:1.1.2025 10:15, but I will receive it 10:20. But I need to store the original system's timestamp and retroactively stop the SLA on the original timestamp, and not the timestamp it was synchronized to SN. The problem is, the 3rd party tool can NOT do PUSH, which would remove this problem completely.

Any idea, different than just basically post-processing the SLAs through some shady business rules?

Thanks!

[Ernesto di San1]

Maybe it's too late and no longer needed, but I managed a similar case by using a Business Rule which changes the "Stop time" field of task_sla record (my task SLAs) and then execute a Refresh action via code (I'm executing the same code used in the Refresh UI Action).

Anyway, I understand the hesitation of some users in previous replies, this method could be used by operators to bypass the SLA breaching process..