This article contains the following topics:
This article contains the following topics:
Request areas define the logical groupings into which you can organize request, incident, and problem tickets. For example, tickets pertaining to an application can be assigned to the predefined Applications area. Whenever an analyst assigns a ticket to a request area, all the information you have associated with the request area is automatically entered on the ticket. For example, if you indicate a service type, it becomes associated with the ticket and all its associated service type events.
The same area definitions are available for request, incident, and problem tickets. On the CA SDM Web Interface Administration tab, these areas are referred to as request/incident/problem areas. For brevity, they are referred to here simply as request areas.
You can set the status of any request area to active or inactive. When you make a request area inactive, it is no longer available for analysts to use, but it is not deleted from the database. If you decide later to use the request area, you need only change the status back to active.
You can use request areas to do the following:
- Specify default values for the group and assignee fields on tickets.
- Automatically associate a level of service to tickets by assigning a default service type to the request area.
- Associate a survey with a request area.
- Select and report on tickets by area by defining your own custom request areas. Eventually study request trends and analyze problem causes. Focusing your view to specific request areas can help make these studies more significant and revealing.
The following predefined request areas are installed with CA SDM:
- SoftwareSoftware is subdivided into several request areas.
Request/Incident/Problem Area Properties
You can use properties to add custom attributes or qualities to a specific request area. If you have added properties to a request area, when an analyst assigns a ticket to that area the associated properties automatically appear on the ticket's properties tab. For example, you can add properties to the predefined email request area to specify the email server or mailbox size.
As you define properties, you can specify whether a value is required or optional. For properties with a required value, users must enter a value (or accept the default) before they can save the ticket.
The keep_tasks option determines what happens when you assign an existing ticket to a different request area:
- If keep_tasks is not installed, existing properties (and workflow tasks) are removed from the ticket, and any properties or tasks associated with the new request area are added.
- If keep_tasks is installed, existing properties and tasks are retained on the ticket, and any properties or tasks associated with the new request area are added.
Property Validation Rules
You can define validation rules to restrict the property values users can enter to a predefined set of selectable values. For example, if you have defined a property named Operating System, you can define the validation rule as a drop-down list containing the options Windows, UNIX, and Linux.
Properties defined without validation rules are presented to the user as free form text boxes, which allow any text string to be entered. Validation rules make reporting on area and category values less complex and less error prone.
Property validation rules are reusable. They are not specific to a particular property. You can apply any existing validation rule to properties defined for change categories, issue categories, or request/incident/problem areas.
Depending on which type of validation rule you have configured for a property, when the user assigns a ticket to the category or area to which that property is attached, one of the following controls appears on the ticket properties tab:
- Text Edit Box—No validation rule has been defined and no default value can be specified. Users are expected to enter values that follow the examples you provide.
- Check Box—A two-state check box appears on the Properties tab. By default, the check box does not contain a checkmark. The user can accept the default, or select the check box. Boxes that contain a checkmark are displayed on the ticket detail page with Yes in the value column. Cleared boxes are displayed with No in the value column.
- Drop-down List—A drop-down list containing a predefined set of options appears on the Properties tab. If you have defined a default value, it is selected when the drop-down list is first displayed. The option the user selects is shown in the value column of the ticket detail page.
Create Request/Incident/Problem Areas
Request/incident/problem areas define the general areas into which request, incident, and problem tickets can be organized. Categorizing these ticket types lets you generate reports, study trends, and analyze problem causes.
To define a request/incident/problem area
- On the Administration tab, browse to Service Desk, Requests/Incidents/Problems, Areas.The Request/Incident/Problem Area List appears.
- Click Create New.The Request/Incident/Problem Area Detail page appears.
- Complete the fields as appropriate.
- (Optional) Use the controls available on the tabs at the bottom of the page to configure the following features:
- PropertiesDefines custom properties to apply to tickets assigned to this area.
- Auto AssignmentSpecifies how tickets in this area are auto assigned.
- Click Save.The new request/incident/problem area is created.
Attach a CA Workflow Process Definition
Note:Unlike change categories and issue categories, which support both CA Workflow process definitions and CA SDM classic workflows, request/incident/problem areas support only CA Workflow process definitions. For more information, see the
Administration Guide. For information about integrating CA Workflow with your CA SDM installation, see the
The Workflow Tab allows you to select a CA Workflow process definition for the request/incident/problem area. A workflow specifies tasks that must be completed on tickets associated with that area.
To allow flexibility, you can define workflow tasks as optional, which allows the analyst to delete them from the task list.
All mandatory workflow tasks must be complete before the ticket can be closed. The only exception is that if the ticket status is set to Cancelled, the workflow process terminates automatically.
If a ticket is removed from an area with an attached workflow, or assigned to a different area, the workflow process terminates automatically. If the new area has an attached workflow, its process starts automatically.
To attach a workflow process definition to a request/incident/problem area
- Select Service Desk, Requests/Incidents/Problems, Areas on the Administration tab.The Request/Incident/Problem Area List appears.
- Select the area to edit.The Area Detail page appears.
- Click Edit.The Area Update page appears.4. Select the Workflow tab and click Add Classic Workflow.Note:The button is only present on systems where CA Workflow is installed and configured to work with CA SDM. For more information about workflows, see theImplementation Guide.The Workflow Definition List appears.
- Click Save.The Area Detail page displays a Save Successful message.
Define Request/Incident/Problem Areas for Self-Service
The Self-Service Include option lets you define which request/incident/problem areas to include on tickets for self-service. You can also define different self-service symbols than those seen by the analyst. When the ticket is saved, the self-service symbol displays in the Request/Incident/Problem Area field. If the ticket displays in the analyst interface, the normal symbol for the area appears. The self-service user is not allowed to edit the symbol; it is read-only.
Follow these steps:
- On the Administration tab, select Service Desk, Requests/Incidents/Problems, Areas.The Requests/Incidents/Problems Area List appears.
- Select Edit In List.The top portion of the page displays the editable fields.
- Open the desired incident/problem/request area for editing on the Symbol list (Hardware.pc.install, for example).
- Complete the following fields:
- Self-Service IncludeSpecifies whether this request/incident/problem area is shown in the self-service interface.
- Self-Service SymbolSpecifies a unique identifier for this request/incident/problem area in the self-service interface.
- ActiveSpecifies whether the request/incident/problem area is active or inactive.
- Click Save.The updated request/incident/problem area appears in the Request/Incident/Problem Area List when you redisplay the list.