- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-23-2017 08:47 AM
Hi,
I need to set up some SLA(s) where the clock runs 24x7, but the SLA threshold varies according to the time of day.
i.e.
A. Logged/Created During working hours, SLA is 30 mins - and the clock runs 24x7
(otherwise I understand the clock would pause when we go out of hours for a ticket logged very close to the end of working hours)
B. Logged/Created Outside working hours, the SLA is 2 hours - and the clock runs 24x7.
How might I do this?
I've been fishing about with Relative times - and I THINK I could go from 'zero to breached' in an instant by setting the StartTimer to have a retrospective start and monitor the Created Time as being At of before 2 hours ago. -but... that doesn't allow for workflow processes to send reminders at 50% of the time etc.
Any suggestions?
cheers
Martin
p.s. I'm a novice, so please excuse any newbie mistakes.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-23-2017 09:02 PM
Hi,
You can easily achieve this by using a relative duration.
Sample script for the relative duration would look like:
var inSchedule = new GlideSchedule("08fcd0830a0a0b2600079f56b1adb9ae").isInSchedule(new GlideDateTime());
if (inSchedule) {
calculator.calcDuration(30*60);
}
else {
calculator.calcDuration(2*60*60);
}
The logic is pretty simple:
1. Have a pre-defined schedule that gives you the working hours and non-working hours. Get the SysId of that Schedule. In this example I have used the OOB 8-5 weekdays.
2. Use the GlideSchedule API to initialize the schedule and understand if the current time is in Schedule (within working hours) or not.
3. If within schedule (working hours), set the due date to be 30 minutes from now. If not within the schedule, set the due date to be 2 hours away.
Note: We need to use the calculator object that is available OOB in the Relative Duration script include. Use the calcDuration API to add the number of seconds relative to current time.
You can then use this relative duration in the SLA Definition. Ensure to set the "Schedule source" in SLA Definition to "No Schedule", else as you mentioned earlier, the Task SLA will pause once it gets into out of business hours.
I am attaching the sample XML files for the Relative Duration and SLA Definition. You can tweak these to suite your business needs. Instead of hard coding the schedule, you can derive the value at run time from the Task table or any of the fields on the Task that have a schedule specified on them. Ex: Caller, etc.
I have tested this in my local instance, and it works fine. Let me know if you face any issues.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-25-2017 03:31 AM
Can you explain your use case. What would be your pause condition, and how do you intend to calculate the new end time when exiting pause stage.
It would be a good input for us to understand and consider this for a future release.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-26-2017 12:55 AM
Hi Aditya,
Ah…. I understand the challenge now - The end time is regarded as an immovable object when using a relative duration.
i.e. For durations like 'before end of day on last day of month', it makes no sense to support pause criteria — since the yardstick is the end of the month! So although the
duration has been calculated for the SLA, it needs to be static because of the 'nature' of 'the end of the month'.
In my circumstances the duration is mixed-mode. — the duration may be calculated, but it doesn't need to be static — since I don't care about overrunning '2 hours from now' if the pause is valid. So, I suggest it needs to have an option to work differently…
Perhaps, when an SLA is being configured with a Relative Duration, the Pause 'config section' could have a tickbox for 'Allow pause to extend SLA deadline past initial Relative Duration end point' (or suchlike). — at which point the pause criteria can be made available, and can operate like they do for 'non-relative durations'.
Of course it might make more sense to put the switch into the Relative duration config itself. — explicitly either 'preventing' or 'allowing' Pause criteria to be available to extend the initially calculated deadline.
cheers
Martin
p.s. And another thing 🙂 As a newbie, the SLA definition regime seems odd. - If something needs to be resolved 'within 2 days', then as a person I would really like to be able to just say to the system 'within 2 working days using THIS schedule'. At the moment I have to work out how many hours are in each day of the schedule that I care about, and tell the system '16 hours' - in order to achieve 2 days-worth of working days on the 8-hours-a-day schedule I have selected. - and if the number of hours in my working day configuration changes, then I have to go and mess with all my SLA definitions. CURRENTLY If I were to tell the system '2 days', I end up with 48 hours (6 working days) - which is utterly counterintuitive to non-insiders. I am a dev, but this feels just too dev oriented rather than SLA designer oriented. I'm happy if you want to make this another thread(or kill it), but I wanted to chip it in here while we were discussing. Perhaps a different option under the 'DurationType' dropdown could be added, to allow for an alternate approach to durations e.g. "User Experience Duration" (Or "Working Days Duration") as well as "User Specified Duration". Anyhow, thanks for listening to my rant 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-26-2017 05:03 AM
Martin,
This is indeed good feedback to us. Yes, we have heard often times how new users to SLA face the challenge in specifying the number of hours. We tried to make it more explicit and easier to understand by putting annotations on the SLA Definition form, that indicate when the SLA would breach assuming it starts now.
But I definitely agree that there is scope for more improvement here.
Thanks for the feedback. We will see how we can make it easier to specify the duration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-26-2017 08:58 AM
Hi Aditya,
Great, thank you.
I had a thought... my original problem (the one for which you provided some code) only exists because what I REALLY wanted to do was set up some Start Criteria that took in to account the time of day.
So an ideal solution for that might look like being able to add start criteria like...
IF CREATEDTIME "Is Within Scheduled hours of" MYSCHEDULE
Such a feature would solve the first part anyway - and might be a useful feature all round.
Anyhow, thanks for your help and your interest in some ideas.
cheers
Martin

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-26-2017 01:03 AM
Hi Aditya,
How can we not give pre-defined schedule rather create it dynamically during run-time.
Suppose, I have 2 fields Open Time and Close time in Location Table. Then in incident SLA, how to create a schedule dynamically such the Start Date time of schedule should be Open Time from location table and End Date time of schedule should be Close time from location table.
For instance, I want to run SLA of 12 hours and schedule should be as defined above criteria. How should I proceed to implement this.
Thanks in advance,
Amrit Sharma