- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-06-2016 12:21 PM
We have a global client where we need SLAs to be based on their locations time zone. For example:
At the moment we have a one P3 Resolution SLA of 1 day that uses a schedule of 8 - 5 weekdays and the timezone on the SLA definition is (System)/US Eastern)
What we need now is that same SLA for a location for example in London. However it needs to be running for 8 - 5 in London no the Eastern US.
We also need to see what incidents' SLAs are actually running. For instance in a list of incidents for this client I need to see when I look at the list at 4 am that the SLAs on the London incidents are ticking away and the ones for the the Eastern US are stopped. And then once 8 am EST hits the Eastern us one starts ticking away and then at 12 noon EST - London stops.
I am thinking that I add the timezone field to the location records. And build new P3 SLAs per timezone and add a condition to the SLA somehow to use the locations timezone. Such as if the location is in the London time zone P3 Resolution - LON gets attached basedon a condition of location.time_zone is LON.
Or is there a way that the system handles this by default or in a simpler manner?
Solved! Go to Solution.
- Labels:
-
Incident Management

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-06-2016 12:26 PM
Hi Kevin,
One of the options inside the SLA definition is to run the timezone based on the callers timzone (or the callers location if you prefer that).
This worked great for us as the SLA definition uses the timezone form the caller to drive the schedule.
Hope this helps.
Cheers
Carl.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-06-2016 03:15 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-06-2016 12:32 PM
Hi Kevin,
I think you are looking for floating timzone: http://wiki.servicenow.com/index.php?title=Using_Schedules#gsc.tab=0
Look under section 2.1 Creating a Schedule
I have not tried it myself, though.
hope this helps.
Harel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-06-2016 12:49 PM
Hi Harel! I don't think so because my resources driving the incidents are all in the Eastern US time zone - I more want it based on the user. Floating seems to say that the SLA is active for the resource looking at it in their timezone.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-06-2016 03:42 PM
Hi Kevin,
Your original requirements are met with base system functionality.
- What we need now is that same SLA for a location for example in London. However it needs to be running for 8 - 5 in London not the Eastern US.
Assuming this is Geneva or later, you configure this as follows:
- If your business hours are always 8AM to 5PM, you use one floating schedule of 8AM to 5PM.
- You configure your SLA Definitions so they all specify your one floating schedule and use the SLA Definition schedule.
- Alternatively, you can populate whatever schedule you want into a schedule reference field on your incident (or whatever task table this SLA is for).
- You configure your SLA Definition to use the task's location time zone.
Per the various system documentation and my other blog post you have already read, your new task_sla records will be created with the correct schedule and time zone so they will calculate properly for the desired location and assignment group. And for tracking and reporting purposes, all you need to do is check the time zone being applied for the calculations.
Let me walk you through how the system handles date/time values, and how your task_sla records are going to behave.
- ServiceNow uses a Date/Time database type for GlideDateTime values.
- Ultimately, this is a large integer number (the number of milliseconds since 01 January 1970 00:00:00 GMT).
- Because we know it is a date/time data type, and a large number of milliseconds is not user-friendly, it is converted into a user-friendly format.
a. We see if there is user-specific date/time formatting, and if the user has a specific time zone.
b. If there is not user-specific settings, we will use system properties to determine the default date/time formatting and default time zone.
c. We render it in that format and adjust it to the timezone.
d. The client will use this format in form and list views, and it is the equivalent of using the GlideRecord .getDisplayValue() method to render a GlideDateTime.
e. If you do a Show XML on a form and look at the date/time value, it will be rendered in internal system format, or yyyy-MM-dd hh:mm:ss GMT.
- If you create a record as a user in US/Eastern time, if you look at any of the date/time values, like Created or Updated or Due Date or Planned End Time, you will see it in US/Eastern time on the form or list while you are logged in as that user.
- If you do a Show XML on the record, those same date/time fields are going to display as GMT.
- If you log in as a user on US/Pacific time, those date/time values are going to display in US/Pacific time; 2016-01-01 12:00:00 America/New_York shows as 2016-01-01 09:00:00 US/Pacific time.
- If you log in as a Europe/London user, 2016-01-01 12:00:00 US/Eastern shows as 2016-01-01 17:00:00 Europe/London.
- If you log in as an Australia/Melbourne user, 2016-01-01 12:00:00 US/Eastern shows as 2016-01-02 04:00:00 Australia/Melbourne.
Because of the way you specify the schedule and the time zone and it is kept in the task_sla record, it will correctly account for the time for whichever location time zone you are applying. But as always, it will display as your local time.
Do note that because of the way this is set on task_sla creation, once you start one of these task_sla records, if you want to change either the schedule or the time zone you need to reset the record and start over, or create a new one. You can't do the calculations partly with one time zone, change the time zone, and continue with the calculations.
Regards,
Ed