This article contains the following topics:
This article contains the following topics:
The SLA model includes the Service Contract. The Service Contract defines the SLA for a particular organization, including its Service Types, Request areas, and Issue or Change Categories. These definitions are referred to as
privateCategories and Service Types can only be used on tickets where the Service Contract is used.
The Service Contract applicable to a ticket is determined by the ticket’s
affected organization, which is always the Organization of the Affected End User on the ticket (this is the Organization field on a Contact record). Only the Areas or Categories that are listed on the Service Contract can be selected for the ticket. In addition, the only Service Types that can be applied are the
privateones that are listed on the Contract. This ensures that the SLAs for one Organization are not accidentally mixed with another’s.
A Service Contract also maps Service Types to common reference fields on a ticket, such as Priority and Asset. This mapping associates Service Types with attributes of a ticket. For example, an Organization’s contract can assign Service Types to each of the five Priority objects. When a ticket is created with a certain priority, the mapped Service Type is applied.
Categories and Service Types can be defined outside of a Contract and are considered
public. The public definitions are used when a ticket has no Service Contract. The lack of a Service Contract can occur if the end user has no organization, or the organization’s Contract is inactive. A public definition is a helpful backup or default mechanism. Public Service Types are set directly on categories and other reference field objects.
All applicable Service Types are assigned to the ticket. This ensures that all aspects of an SLA are visible and enforced, for example:
- A Printer may have a Service Type that requires a technician to be dispatched within two days.
- A priority object’s Service Type may require a callback within one hour.
With both Service Types applied, these required actions are enforced.
Tracking multiple Service Types also helps prioritize tickets. For example, a ticket concerning a broken keyboard is assigned a low priority Service Type. However, if the affected end user is in urgent need of the keyboard, the service priority can be increased.
The SLA model is enforced by default. Past versions of CA SDM applied only a single Service Type to a ticket. The Service Type selection that is involved finding the highest
rankedType among all the possible Service Types. A model using the ranking scheme can still be used by installing the Option ‘classic_sla_processing’.
Service Contracts Example Use Case
ABC Inc, has configured CA SDM environment in a way that SLAs are associated to Service Types, and these Service Types are linked to priority
The SLAs are acceptable in most circumstances, however a group of VIPs require a faster resolution time than what the normal SLAs provide. In such a case, Service Contract can be created to accommodate this.
A Service Contract can be configured for special private Service Types which can contain different SLAs than those used by the default Service Types. These private Service Types can be mapped to a Priority or Urgency. You are then able to associate specific Users, Groups, or Configuration Items to this Service Contract that it applies to.
- CEO ofABC Incis associated to a specific Service Contract, that would have special SLAs.
- A specific server at ABC Inc requires high availability which can be associated to a Service Contract so that if a ticket were created for that Configuration Item it would be associated to the special SLAs.
You may link a Service Contract to an Area\Category, so that if they were specified in the ticket they would be associated to the special SLAs too.
A Service Contract is not a replacement for SLAs, it provides a method to associate unique SLAs to certain situations to help meet the business requirements.
Service Contracts Migration
If CA SDM is installed as a migration, the Option classic_sla_processing is turned ON by default, so your SLA processing can continue as before the migration. This continuation gives you time to create appropriate Service Contracts and eventually deactivate classic_sla_processing.
When building Service Contracts, you do not have to create Service Types, Request Areas, or Categories. You can use the Copy button found on the Service Contract detail to copy existing objects to the Contract.
If the previous installation marked the support_lev field as required for any ticket type, this restriction must be removed. The support_lev field still exists, but is not set in the current model so a required field error results with new tickets. This affects the objects Request (cr), Issue (iss), or Change Order (chg).
Time to Violation
When the SLA model is in use, CA SDM's Time to Violation (TTV) system can help you track and prioritize tickets according to their projected violation time. This system monitors all active tickets and sets the projected violation time for each Service Type. You can report and sort tickets based on their violation time and cost, helping you resolve the most urgent and costly issues first.
The TTV system monitors all active tickets and evaluates their SLA events silently, to determine which events set the SLA violation flag. The events are not executed, but the system looks at the outcome of each event based on the current state of the ticket. If the evaluation results in an action that sets the SLA violation flag, the ticket’s attached Service Type is updated with a Time to Violation value; this value is the date/time when the event fires that sets the SLA violation.
Evaluation occurs whenever a ticket is inserted or updated. Because tickets are often updated in rapid succession, the evaluation is delayed for a short period. The delay interval is controlled by the ttv_evaluation_delay Option. After the delay expires, the TTV system evaluates all the SLA events that might set the SLA violation flag.
Each Event has an optional condition and a set of actions (Macros) that start based on the outcome of the condition. To ensure adequate performance, Event template information is cached by the TTV system and is refreshed periodically. Projections that are made by TTV involving recently updated Event templates may be inaccurate for several minutes.
The TTV projections appear on the Service Type tab of each ticket. The TTV system is activated with the ttv_enabled Option.
Time Zones and Workshifts
To address the complex business demands of automated application execution, CA SDM lets you define as many time zones and workshifts as you want, and to record them for easy reference.
- Time zones identify the time zone where the user, CI, and so forth, are located.
- Workshifts define the period during which event monitoring or the work hours of a service type or SLA are in effect.
Being able to determine a course of action to perform based on when an event occurs can be critical to the proper handling of the event. The time zones and workshifts you define are available for use by any of the CA SDM functions.
Time Zones Setup
Time zone codesdefine the time zone from which a user usually accesses the system (that is, the user’s local time zone) or the time zone in which a CI is located. Business hours are always entered in the time zone of the CA SDM server. This means that business hours can always be compared uniformly.
Time zones are used to manage service types, escalations, and overall response to affected end users based on the ability of CA SDM to present the correct time across multiple time zones. CA SDM automatically adjusts the offset between the time zone where a user is logging in or a CI is located, and the time zone where the server is running. Time zones use the Greenwich Mean Time (GMT) format.
How to Manage Multiple Time Zones for Service Types
CA SDM servers and users can be located in different time zones. The time difference can cause users to miss Service Type expiration dates and times.
To correct the time difference, you can configure CA SDM to display Service Type expiration times in the end-user time zone. If two users in different time zones view the same ticket, each user sees Expiration Time values based on the local computer time zone. However, the Start Time values always reflect the server time zone.
To configure for the end-user time zone, do the following:
- Create a server code that identifies the server name and time zone.
- Create or update a Service Type. Set the Use End User Time zone field to Yes.A value of Yes causes the Expiration Time to display and update according to each user time zone.
Example: Show Service Type Expiration Dates in Any User Time Zone
In this example, you configure CA SDM to show Service Type expiration dates in any user time zone. The server and user are on separate computers and in different time zones.
To create a server code that identifies the server name and time zone
- On the Administration Tab of the host server, select Service Desk, Application Code.
- Click Codes, Servers.The Server List displays
- Click the Local Host server.The Server Name Detail page appears.
- Set the Time Zone. For example, set the time zone to GMT (EU). The local host name must match the NX_LOCAL_HOST value that is stored in NX.env for the server
- Click Save.The Host Server uses the new time zone. When the user views a ticket, the Start Time reflects the server time zone.
To create a service type
- On the Administration Tab, select Service Types.The list of Service Types appears.
- Click Priority 1 Resolution or another Service Type that manages Priority 1 Requests.The Update Service Type page displays
- Select the Use End User Time Zone check box.
- Click Save.The Service Type record is updated
To view the time zones on the ticket
- On another computer, open a Request ticket, and set the Priority to 1.If you are using Service Targets, set the values in the ticket to cause the target to use Priority 1 Resolution.
- View the ticket and click the Service Type tab.The Start Time reflects the server time zone. The Expiration Time reflects the time on the end-user local computer.
- Close the page that displays the Request ticket.
- Change the time zone on the end-user local computer.
- View the ticket Service Type on the end-user local computer to see the corresponding Expiration Time values based on the user time zone.The Expiration Time reflects the new time zone.
Workshiftsidentify the days, dates, and times when an event or schedule is in effect. You can specify days or dates, or days and dates. Specifying a time is optional.
When you are monitoring events for tickets, workshifts define when the event is monitored or, in other words, when the clock is running. For example, using the predefined event P1 Active Issue Notify assignee, if a priority 1 issue is opened at 4:45 PM and the workshift schedule is 9:00 AM to 5:00 PM, the monitored event automatically sends notification to the issue assignee at 9:45 AM the next day.
Workshifts are also used for the purpose of automatically assigning tickets to contacts.