Layton ServiceDesk - Configuring the System - Create and Define Libraries

Revision as of 04:15, 16 September 2010

Setting Up Libraries

The next stage is to define the library information. Libraries are user-defined and provide pre-determined information or structures needed for creating and progressing Requests, Problems & Changes.

Although it is advisable to create the Libraries before implementing the system, they can always be added to or changed at any time by Analysts with Administration access. Any changes will be cascaded through the system so all records will be amended accordingly. All menu options are located using Administration | Libraries.

• Request Classes
  
• Request Type
  
• Request Statuses
  
• Request Templates
  
• Task Types
  
• Recurring Tasks
  
• Priority / SLA
  
• Problem Statuses
  
• Change Types
  
• Change Statuses
  
• Services
  
• Impact
  
• Urgency
  
• Email Key Words
  
• Cost (Catalogue) Items
  
• Email Bodies
  
• Drop Down Lists
  
• Brands
  

>> Return to Table of Contents <<

Request Classes

Request Classes are used to define multiple Request forms, for example; Incident Request or Service Request or New User Requests. Different forms can be designed for Request, Spawned Request and End User Request for each Request Class. See the FORM DESIGN section for more details. When a new Request Class is initially created, the newly created Request Class will inherit its associated Forms from the (Default) Request Class. By default Layton ServiceDesk™ ships with one default Request Class.

Request Classes can also be linked to Request Types so only certain Request Types are displayed for a particular Request Class. Simply select the edit button in the Request Type column and a pop up window will display the full list of available Request Types. Apply a check next to the Request Types that are to be displayed when logging a request for this Request Class.

When creating a Request Class there are two options available for “Add to New End User” and “Close Request When Tasks Completed”. If the “Add to New End User” option is selected any new End Users that are added to the system will automatically be given access to this Request Class. If “Close Request When Tasks Completed” is selected then a Request will be automatically closed once any Tasks associated with the Request have been completed.

Request Type

The Request Types are the user-defined method of categorizing or grouping Requests and Problems. They are used as the basis for assigning individual Analysts and Groups according to Skills and they also link to the Solutions Base.

Request Types can either appear as a tree structure with no limit to the number of levels or as inter dependent drop down lists. Any level in the structure can be used when logging a Request or Problem. For example a Request Type could be specified as PC Hardware Fault only or a specific problem within PC Hardware Fault structure, such as CD Drive Failure.

Figure 2 - Manage Request Types

Request Types can also be linked to Request Classes where only certain Request Types will be displayed or made available to a Request Class or form selected.

So, careful thought must used to define the Request Type structure that will support your particular business and operations.

To set up Request Types go to Administration | Libraries | Request Types. Then simply select the Request Type or name at the tree level above the level you require to insert a Request Type and click the Add New button. A new sub level can then be defined. To create a new top level Request Type click on the Request Type name at the top of the tree structure and click the Add New button. To edit an existing Request Type simply click on the Request Type and the options will be displayed.

To relocate a Request Type within the tree structure, simply drag the request type to the desired parent location. You will then be given the option of making the Request Type a “Sub-Category” of the parent request type or merging it.

When defining a Request Type you can specify a default Priority to place against it. For example, you might want to define a Request Type such as “Server Down”. This might be a high priority Request Type, so you can specify a Priority to put against it. This means that when selected on a Request the Request Type Priority will be applied to that Request where the specific Request Type is chosen. Note; this will override the default system priority.

You can also define a Site or Department Manager or specific Analyst responsible for a particular Request Type. The Request will be automatically assigned on this basis and will override any other assignment rules (except for any Business Rules). For example, a certain type of Service Request may have to be authorized by a manager before being assigned based on skills.

A Request can be defined as an “Incident” which means the Request will be automatically measured against the ServiceDesk available time. The Request Statistics by Incident Report will show the “down time” as a percentage of the available time. This is useful for measuring availability of business critical Hardware or Software Systems.

To display Request Types as inter dependent drop down lists instead of the tree view when processing Requests, the Request Type field is simply added to the Request Form (using Form Design and adding the sys_requesttype_id), as many times as there are levels in the structure. Then by selecting a category from the top level drop down list only the sub categories of that category will appear in the next drop down list.

If you are using Analyst Skills or Group Skills to prompt for assignment, once you have completed the Request Types you can now add Skills to the appropriate Analysts or Groups. See the previous sections Manage Analyst and Manage Analyst Groups.

Also, remember the Request types are used as the main or automatic link to identify a Solution within the Solutions Base. See the SOLUTIONS BASE section for details.

>> Return to Table of Contents <<

Request Type Task Templates

The Request Type Task Template feature provides the ability to create a number of pre-defined Tasks that will be automatically created when an Analyst logs a Request and selects this particular Request Type. The Tasks can be dependent on other Tasks if required. All Tasks will be created simultaneously and arranged in order of dependency. If a task is dependent on another Task then it will not start until the dependent Task is completed. It is also possible to have a Request with multiple simultaneous Tasks.

To create a Request Type Task Template select the desired Request Type in the Request Type tree structure and then click on the Manage Task Template icon . If two or more Tasks are added to the Task Template and dependencies are required, then the Dependency column should be selected for the appropriate Task. Tasks that are dependent will have the Task Date or Date Placed set to blank. Also in the list view of Tasks the Completed Date will show as “Dependent on other Tasks”. The Request can also be automatically closed upon completion of the final task and this is defined when creating / editing Request Classes within Admin | Libraries |Request Classes.

Request Statuses

The Request Status identifies the stage or status of a Request. The normal stages are open or closed however you can add any others such as, “suspended” or “on hold”, etc.

• To add, delete or change a Request Status use Administration | Libraries | Request Statuses.
• To add or delete select the appropriate action and to modify simply select the Request Status and rename as required. You may also set the “Suspend” flag on a status that allows you to make that status freeze the escalation process.
  

Note: You cannot delete the Closed Status.

The default Status for all Requests is set to “Open” but can be changed using Administration | General Settings |Request Settings and set the Default Status. Once a Request is recorded you can change the Request Status by using the “Change Status” icon on any of the Request List Views, or from the “Change Status” icon on the request form.
You can also edit specific properties of the status (other than the “closed” status). Properties such as if the End user can use the status, forcing the status color, and choosing the color to force. The Force status color option is useful for when a request is put on hold and changing the default color to something other than white, to easily identify from the home screen list views which requests are on hold.

Request Templates

Request Templates allow you to pre-define Request information that can be dropped into the Request form by using the apply templates icon when entering a Request or via the QuickAction menu. The Request Template uses the same form definition as the Analyst Request form and any information specified in the Template will drop in over the same fields when applied. Any blank fields in the Template will leave any information in the request un-touched. To create a new Request Template go to Administration | Libraries | Request Templates and click the Add New Icon. If you are using Request Classes you will be presented with a pop up which allows you to choose the required Request Class. You are then presented with the Analyst Request Form. Simply fill out all of the information in the Template and click the Save icon. A new template is saved with a Default Template name such as Template X. You can rename the Template by clicking the Edit Icon in the manage Request Templates screen. The Templates are very useful for common Requests that are logged several times daily. This will expedite the call logging process when Templates are used to pre-define the Request Type, problem description, and solution fields.

Task Types

Tasks or Actions are activities that are required in order to progress or complete a Request, Problem or Change. Alternatively, they can be free standing without any association and could include planned maintenance activities (See Recurring Tasks below). Actions can be scheduled for completion on a certain date and assigned to any Analyst with the current assigned Analyst as the default. Tasks are added by selecting the Task icon on the Analyst Request, Problem and Change forms or via the Quick Action menu or the Log New menu on the Analyst Home tab. Task Types are user defined and use a tree structure similar to the Request Type tree structure.

To set up Task Types use Administration | Libraries | Task Types. Select the Task Type or name at the tree level above the level you require to insert a Task Type and click the Add New button. A new sub-level can then be defined. To create a new top level Task Type click on the Task Type name at the top of the tree structure and click the Add button. To rename a Task Type simply click on the Task Type and the option will be displayed.

To relocate a Task Type within the tree structure, simply drag the Task Type to the desired parent location. You will then be given the option of making the Task Type a “Sub-Category” of the parent Task Type or merging it.

>> Return to Table of Contents <<

Recurring Tasks

Recurring Tasks are Tasks that are created automatically according to a pre-defined schedule and are typically used for routine maintenance activities. A Recurring Task can be an individual task or a number of Tasks with a dependency workflow.

To create a Recurring Task go to Administration | Libraries |Recurring Tasks. Click on the Add New button and in the pop up window specify the name and schedule. When this window is saved the Task Form will be presented. Complete the Task template and then when you click save it will add the Task to the schedule. Please note that the following system fields on the Task form will not be available for selection as they we be automatically generated when the Task is created; Date Placed, Status, Scheduled Date, Completed Date. Also the Request ID, Problem ID & Change ID fields are not editable as the Recurring Task will not be linked to a Request, Problem or Change.

Once you have added a Task if you would like to add further Tasks to this Recurring Task schedule simply click on the Add button and create another Task. If a dependency workflow is required click on the Dependency column and specify the require dependence.

To view, edit or add another Task for an existing Recurring Task schedule, click on the Tasks icon for the relevant Recurring Task.

The Recurring Tasks are managed from the Administration |Libraries | Recurring Task section, however if required the Recurring Tasks can also be displayed on a separate tab next to an Analysts View My Tasks list in the Main Menu | Home | View My Tasks. This option is an Analyst Security Setting which can be found at Administration | Company Structure | Manage Analyst | Settings |Recurring Task Access.

Priority / SLA

Priorities dictate the importance of Requests and escalation times and routes. They are user configurable and are defined within a SLA, and although SLA’s as such may not be required, in order to set any Priority, an SLA name or title is defined.
Generally the Priority of a Request (or Incident) is determined by the Impact and Urgency of the issue. For example an issue that is affecting a single user and has a high urgency would be given a lower Priority than an issue that is affecting the whole company and has a high urgency.

A Priority / SLA can be implemented using predefined resolution and escalation details. Alternatively, the resolution time and any escalation details can be set manually or the predefined values amended when logging a Request.
Even if no escalation or resolution times are needed, the Priority is still defined within a SLA title (but could be blank) but with no escalation parameters set. Priorities and SLA’s are defined using Administration | Libraries | Priority / SLA.

Priorities and escalation details are defined against each SLA as follows:

• First set the Priority identity. If you are not using SLA or escalation times or you only have one SLA, then this could simply be “A”, or “B”, etc. Alternatively, for multiple SLA’s this should include the name of the SLA, i.e. “SLA1 – A”.

SLA Information:

• If SLA information (resolution and escalation details) is not required to be pre-set for the Priority then leave all fields blank. Then decide whether any escalation or expiry details will be entered manually at Request logging.

If “Allow Escalation Edits (At Request)” is set to “No” then no expiry or escalation times will be set and the Priority will only be used for identification and reporting. If set to “Yes”, then resolution and escalation times can be entered when saving the Request. To save the Priority / SLA details, select the “Save” icon, then continue to create additional Priorities as defined below. Setting the option to Yes allows all analysts to alter the escalation times when the request is to expire.

SLA Information Required:

• If SLA information (resolution and escalation details) is required to be pre-set, then you can enter any field as they are all optional. The resolution time is the number of hours from when the Request was opened. You can then enter from none to three levels of escalation times in hours. Again, this is the number of hours from when the Request is opened.

Please note that the escalation and resolution times take the Default Working Hours into account. You can select to email any Analyst and re-assign the request to a different Analyst for each level of escalation.

>> Return to Table of Contents <<

Adding Additional Priorities:

To continue adding more Priorities to an SLA select “Add New” on the Manage Priority / SLA form and then enter the same SLA name as previous. Otherwise, to define a new SLA, select “Add New” as above but enter a new SLA Name.

See Figure 3 below for an example Priority /SLA and the table in Figure 5 for SLA / Priority requirements and appropriate actions.

Figure 3 - Priority / SLA

Manual Setting

In addition to pre-setting escalation and resolution times against a Priority / SLA, there is also the option to override these times or just set any escalation or resolution time manually. This is achieved by first setting the 'Allow Escalation Edits (At Request)' field to 'Yes' in the Administration | Library | Priority / SLA form. Then any Requests using that priority will prompt the Analyst or user to enter, edit or confirm the resolution and escalation times when the Request is saved. The confirmation screen is displayed below in Figure 4. Simply input or amend any escalation times or the expiry time and select Save. To use or revert to any predefined values for the Priority select the “Use Default” button. This button then changes to “Use Store” which if selected will then revert the settings to those manually selected for the Request.

>> Return to Table of Contents <<

Summary of Priority / SLA Requirements:

Summary of Escalation Process:

The escalation process will be initiated when the resolve time or any escalation level is exceeded. The following processes can be invoked using the Priority / SLA form:

• An automatic email can be sent to a specified address
• The Request can be automatically assigned to another Analyst
• The Request itself as displayed in the list views, will change color

The color setting is defined using Administration | General Settings | Request Settings. By default the Priority escalation color will only be applied to the Priority field in the list views, however if preferred this can be changed so that it colors the whole row. This color setting is found in Administration | General Settings | Request Settings | Color Whole Row.

• Note: If a Request has a “Suspend” status all escalation is frozen until that status is changed to a status that does not have a “suspend status on it”

Problem Statuses

Problem Statuses are used to identify the stage or status of a problem. Typical Problem Statuses would include Open, Pending Change, Known Error, Closed or Resolved. Problem Statuses are user defined and can be created in Administration | Libraries | Problem Statuses.

To add or delete select the appropriate action and to modify simply select the Problem Status and rename as required. You may also set the “Suspend” flag on a status that allows you to make that status freeze the escalation process.

• Note: You cannot delete the Closed or Open Status.

The default Status for all Problems is set to “Open” but can be changed using Administration | General Settings |Problem Settings and set the Default Status. Once a Problem is recorded you can change the Problem Status by using the “Change Status” icon on any of the Problem List Views or from the “Change Status” icon on the Problem form.

You can also edit specific properties of the status (other than the “closed” status), properties such as forcing the status color and choosing the color to force. The Force status color option is useful for when a Problem is put on hold and changing the default color to something other than white, to easily identify from the home screen list views which Problems are on hold.

>> Return to Table of Contents <<

Change Types

Change Types are user defined and are used to categorize Changes. Typical Change Types include, Standard, Normal and Emergency, however any number of Change Types can be created. To set up the Change Types go to Administration | Libraries | Change Types.

Change Statuses

The Change Status will identify the stage or status of a Change. Typical Change Statuses may include; Reviewing, Testing, In Progress, Cancelled, Failed and Completed.

To add or delete select the appropriate action and to modify simply select the Change Status and rename as required.

The “On Status” selection options of Continue or Closed determine whether the status is considered to be open or closed. The Change Statuses can be color coded for easy visual identification within the Change List View.

The default Status for all Changes is set to “Open” but can be changed using Administration | General Settings |Change Settings and set the Default Status. Once a Change is recorded you can change the Change Status by using the “Change Status” icon on any of the Change List Views or from the “Change Status” icon on the Change form.

Services

Services are a list of Business or IT Services that the ServiceDesk will be required to support. Services can be added in Administration | Libraries | Services.

Impact

The Impact is a measure of the effect of an Incident (Request), Problem or Change on a business service or process. Impact is typically used on conjunction with Urgency to determine the Priority. Impacts are user defined and can be created in Administration | Libraries | Impact.

Urgency

The Urgency is a measure of business criticality of an Incident (Request), Problem or Change. The Urgency reflects the time available for resolution or avoidance before the impact is felt by the business. Urgency in conjunction with Impact is used to determine a Priority. Urgencies are user defined and can be created in Administration | Libraries | Urgency.

Email Key Words

Email Keywords allow you to set up Keywords that are used to assign Request Types to incoming emails that are processed as requests (see Converting an Incoming Email into a Request). Email Keywords help to simplify the processing of incoming emails for commonly requested issues.

For example you can set up the keyword “Network” against the Request Type “Network Issue” and if an incoming email arrives with the keyword “Network” in the subject line it will match the keyword to the Request Type “Network Issue” and create the Request with the “Network Issue” Request Type. The Request can then be automatically assigned to an Analyst or Analyst Group with the appropriate Skills and given a Priority if one is pre-defined for the Network Issue Request Type.

Cost (Catalogue) Items

Cost Items are a list of items or services that may be requested or fulfilled in the process of completing a Request, Problem or Change. Catalogue Items a categorized in a tree structure like the Request and Task Types. Catalogue Items can be assigned a cost value and cost items can be applied to Requests, Problems and Changes through the Cost Sheet along with Labor Charges (see Request Costs).

Cost Items can be added in Administration | Libraries | Cost Items. Select the Item at the tree level above the level you require to insert a Item and click the Add button. A new sub level can then be defined. To create a new top level request type click on the Cost Item name at the top of the tree structure and click the Add button. To rename an Item simply click on the Item and the option will be displayed. To relocate an Item within the tree structure, simply drag the Item to the desired parent location.

Email Bodies

Email Bodies allow you to modify the text that is in an automated email notification. In order for the automatic email notifications to be sent the Email Server Settings will need to be configured in Administration | System Settings | Mail Server Settings (see Email Server Settings for details).

The various automatic email notifications can be enabled and the Email Bodies modified by going to Administration | Libraries | Email Bodies. To enable an email select the “Enable” checkbox next to the desired email notification (Note that all of the “Escalation” Emails are grouped together with one “Enable” section which will apply to all Escalation emails). To edit the Email Body click on the “Edit” icon.

To insert system or user fields into the email bodies select the desired field in the field selection list which is displayed on the right of the email body and click the Add button. When the email is generated it will insert the data from this field into the email body. For example in the Email Body for “Request is Assigned – Notify Analyst” you may want to include the Request Type (sys_requesttype_id) and the Problem Description (sys_problemdesc) field. See Figure 6 below for a sample email body.

Figure 6 - Email Bodies

Drop Down Lists

Drop Down Lists are pre-defined lists that can be applied to forms through the Form Design Section (see FORM DESIGN). Drop Down Lists are managed under Administration | Libraries | Drop Down Lists. After creating a Drown List and entering the name select “Items” then continue to add new items to the list by selecting “Add New List Item”. In order for the Drop Down List to be used on any form, say the Request form, a user defined data field should also be added to the Request table structure in the Data Design section (see DATA DESIGN) and then the Drop Down List will be linked to that data field in the Form Design using the Add Drop Down List icon on the floating Toolbar.

Brands

The purpose of Brands is for situations where Layton ServiceDesk will be used in an environment supporting multiple external customers. For example, as you learn to customize Layton ServiceDesk™, you will see you can also customize the Banners, and Admin Banners with a different logo or text. Typically the new logo will be that of the customer who is logging in to the system.

When adding a Brand name, which is the identifier, a Description is required. It is recommended to keep the name short and simple but clear enough to know what it is for. For example, creating a brand called “Microsoft” or “MS”, and description of “Microsoft Brand” and then saving will allow you to use the form design to make further changes to the Brand. Now going to Administration | Form Design | Banner – you will see there are choices for the different Brands. The default is the one provided by the system, where the new one will allow you to customize the banner image, or text to show that of Microsoft’s in this example.

Once a Brand has been defined you can provide the users with this Brand a specific URL address to log into Layton ServiceDesk and this will then display their own personalized Banner. For example using the “MS” Brand used above the login URL would be http://servername/LaytonLaytonServiceDesk/loginframes.asp?brand=MS