CA Service Management

Hello,

We have an issue, the application server is in a timezone different, of the end users. When the user create the ticket the application put the expiration time with the server hour and not with the time zone configured in the user information.

Could you help us with this case because the impact by the user is very higt?

Regards,

I have a similar issue, with an SDM server in Western Australia (UTC+8), and analysts in New Zealand (UTC+12, and currently UTC+13 for summer).  The analyst's timezone is used when displaying times in the user interface, but not it seems when firing events.  My current solution is to create a workshift that expresses the NZ working hours in my (WA) timezone. For example, if the NZ guys work 0800 - 1700, I enter that as a workshift 0300 - 1200 and adjust it by an hour in a scheduled task when summer time comes in (my part of Aust doesn't do daylight saving).  Then I use that workshift for the SLA events.  So far that seems to work well.  I'll be interested to hear of any alternative approaches!

Regards,

James

Hi,

Didn't release 12.x introduced end user time zone?

You suppose to be able to activate this at the service type level by setting the "Use End User's Timezone" flag to yes

The trick is that you must then define the workshift at the servicetype level and make sure to not have any workshift  on the associated event (workshift event will overwrite the service type ones).

as from the help menu:

Symbol

A unique identifier for this service type. Use the symbol to readily identify the service type. For example, to set up a service type that requires a response within an eight hour time period, you might assign the symbol 08_hr_resolution.

Ranking

Service types can be associated with various objects, such as contacts, organizations, categories, and priority codes. If different service types are associated with a ticket, the one that is used depends on the value in this field, where the one with the lowest number has the highest priority. For example, if an issue is opened and the Affected End User contact has a 12-hour resolution service type, which is ranked as 2, while the priority code has a 4-hour resolution service type, which is ranked as 1, the service type for the issue is 4-hour resolution.

You must enter a value of 1 or greater; values of 0 or negative numbers are not allowed.

Workshift

Specifies the dates, days, and hours when the service type is in effect. This usually coincides with the times your service desk is operating (for example, 24 Hours, Regular, or Non-Business-Hours).

The following rules apply to workshifts:

• If you apply a workshift to a service type, you need to stop and restart the service for the workshift to immediately take effect.
• If a workshift for a service type has been specified, but one has not been specified for an event, the service type workshift is in effect.
• If a workshift for an event has been specified, but one has not been specified for a service type, the service type workshift is ignored.
• If a workshift for event and for service type have been specified, the service type workshift is ignored.

Timezone

The time zone for the service type. You can enter the time zone directly in this field, or click the search icon to select the time zone from a list.

This time zone is used for triggering events in the system if the Use End User Time Zone option is not selected.

Use End User's Timezone

Select this option if you want to use the timezone defined for the affected end user on a ticket for triggering events in the system.

Violation Cost

The cost that is incurred if the service type time limit is violated.

My 2 cents

/J

Thanks Jerome, a very useful reminder.  I am attaching SLA events in response to a particular activity notification, to record when the next update on a ticket is due, so they're not currently attached to a service type.  But I'll experiment and see what I can work out. Thanks for the suggestion.

Regards,

James