Planning and Deploying a Help Desk System

This chapter discusses the issues and considerations involved in implementing an Enterprise HelpDesk system. It provides a roadmap of the major steps, identifies the decisions you must make, and discusses the pros and cons of alternative choices.

This high-level information provides a framework for the more detailed information found in the rest of this manual.

Planning

To set up a help desk system that reflects your help desk structure and process, you need a good understanding of that structure and process.

Information Recording and Tracking

What information do you want to record and track for each issue?

How do you categorize issues?

Do you want to provide different views of the issue data?

For example, do you want a summary view optimized for recording call data and categorizing problems, and a detailed view for recording things such as how the problem was resolved, and how long it took?

Workflow

What is your help desk process?

Can you represent the path of an issue through the process as a sequence of steps, or decisions, such as New, Assigned, Verified, Resolved?

Do you want to enforce this “workflow” process?

Who should have permission to make each decision? Who will be responsible for carrying out each step in the process?

Do you need e-mail notifications to enforce ownership and accountability? When issues are submitted or resolved, who needs to be alerted?

Roles and Responsibilities

What are the different roles and responsibilities of your help desk staff? Can you divide users into groups (such as help desk analysts and group leaders)?

Do different groups have different requirements of the issue tracking system? Do you need to restrict access to the system based on group membership?

For example, you probably want to give employees only limited access to the system so they can submit new issues and track the status of submitted issues. Help desk staff, on the other hand, will require greater access to the system.

Implementation Roadmap

This roadmap outlines the major steps in implementing an issue tracking system. Performing the steps in the sequence recommended here will save you time and simplify the process.

Step 1. Create a project

A project defines the fields, queries, sorts, layouts, and reports that you see in a Web view.

Create a new project.

Customize the fields in the project.

Edit and define the queries, reports, sorts, and layouts to match the set of fields defined in the project.

Step 2. Define user groups and create user accounts

Define user groups and set group permissions to control access to data and administrative features.

Create user accounts so people can log on.

Assign users to groups.

Step 3. Define and generate Web views

After you generate and test your Web views, you can perform more advanced customizations, such as defining workflow and notifications.

Step 4. Define field dependencies (optional)

Use the workflow editor in HelpDesk Web Admin to make the possible values in one choice list depend on the choice selected from another list.

You can apply changes made in the workflow editor without regenerating the Web view.

Step 5. Define a workflow (optional)

Use the workflow editor in HelpDesk Web Admin to define workflow rules to emulate your process. For example, you can enforce a sequence of steps by controlling the possible values of the Progress field.

You can also define rules that set the value of a field when another field changes. For example, you can define rules that assign an owner based on the problem area:

When (Problem Area = Outlook), then set this value: (Owner = Resident Outlook Wiz).

Step 6. Import existing data (optional)

After you finalize the set of fields in a project, you can import trouble tickets and call data from existing databases.

Step 7. Define and set up notifications

You can define and set up notifications after you generate your Web views, but you should do this before people start using the Web views to submit issues.

Step 8. Go live

Step 9. System maintenance (ongoing)

You should regularly backup your projects, databases, Web views, and other system files.

You should also run the Repair and Compact utility (Tools menu, HelpDesk Admin) on a regular basis. Compacting Microsoft Access databases and files often is the best preventive maintenance.

Creating a New Project

About Projects

A project defines everything that you see in a Web view: the fields, queries, reports, sorts, and layouts.

Do not edit the default projects (such as HelpDesk) shipped with Enterprise HelpDesk. Instead, create a new project based on one of the default projects, and use this new project as your starting point.

Only members of the Admins group should be allowed to open projects in HelpDesk Admin.

How Many Projects Do You Need?

Each Enterprise HelpDesk project has its own issue database. Projects can share the definitions of things like reports and queries, but the issues recorded in each project database are completely separate.

For example, if you want to record software, hardware, and support issues in separate databases, you can create three separate projects. Separate projects mean smaller databases and better performance. It also means you can customize fields, queries, sorts, layouts, and reports on a project-by-project basis. For example, you don’t need a field to specify the issue type (software, hardware, or support), and you don’t need separate queries for each issue type.

You cannot generate reports across all projects.

You cannot create a single view that covers all projects.

If a help desk analyst works on all three types of issues, separate projects may be inefficient and time-consuming.

Choosing a Base Project

A base project serves as a starting point for a new project. The new project inherits the fields defined in the base project, and can optionally inherit the styles (queries, reports, sorts, layouts, and notifications) as well.

Enterprise HelpDesk includes several default projects you can use as the base project. Before you choose a base project, you should familiarize yourself with the fields included in each project, and understand what you can and cannot do when customizing fields.

Use the HelpDesk project if you want to attach files to issues, or track user and contact information such as e-mail addresses and phone numbers.

HelpDesk

Designed for use by internal help desks, HelpDesk allows you to record and track issues reported by employees.

HelpDesk includes over 60 fields, along with a complete set of reports, queries, sorts, layouts, and notifications based on those fields.

A number of the default fields cannot be deleted. So even if you don’t use these fields, they will take up extra space in your database.

When you do delete a field, you must first remove it from any report, query, sort, layout, or notification that references the field. Deleting unused fields helps minimize the size of your database.

BlankProject

BlankProject includes the absolute minimum: a handful of fields, one query, one sort, one layout, and no reports or notifications. If you don’t need most of the fields defined in one of the other projects, you may want to consider using BlankProject as your base project.

With BlankProject, you don’t have to worry about removing a field from reports, queries, and other styles so you can delete the field. And you can define your own set of fields, tabs, and styles.

However, you cannot attach files to issues unless you manually add an attachment field (see Creating an Attachments Field). And there’s no way to track user and contact information such as e-mail addresses and phone numbers, unless you enter that information into each issue.

Customizing Fields

About Customizing Fields

In general, if an existing field does not meet your requirements, you can either delete it or edit it.

For example, if a field is the right data type and size, but has the wrong caption, you can change the caption. In the case of choice lists, you can replace the table of choices completely.

Before you start customizing the fields, you should familiarize yourself with the fields in the base project, and determine:

Which of the existing fields can you can reuse as is? Or reuse by changing the label, choice table, or tab?

What new fields do you need to add?

Which of the existing fields do you want to delete?

You should also familiarize yourself with what you can and cannot do when editing fields.

What You Can Do

Add new fields.

Change field labels.

Change the list of choices for a choice list.

However, you must update the queries that test the choice values.

If you change the Progress choice list, you should either disable or update the default workflow rules. The default workflow is based on the Progress choice list.

Delete most fields.

To delete a field, you must first remove it from any queries, sorts, layouts, reports, and notification that use the field.

Before you try to delete a field, go through the different queries, sorts, layouts, reports, and notification conditions and either remove the field or delete the style.

Create choice lists where the contents of one list depends on the choice selected from the other list.

For example, Problem Type could be one of Software, Hardware, and System. Problem Area could then be a type-specific list that displays either a list of software applications, hardware components, or system components.

Move fields between tabs, but not through a user interface.

To move a field to another tab, you have to use Microsoft Access to open the .def file and edit a table.

If you don't have Microsoft Access, all you can do is copy the field, put the copy on another tab, then delete the original. However, when you copy a field, you do not copy the data stored for that field. And when you delete the field, you delete all the stored data for that field.

Change tab names, and reorder the tabs.

Disable fields (make read-only) or hide them. Note that when you hide a field, it is hidden in all Web views.

What You Cannot Do

Change field types.

For example, you cannot change a single choice field into a multi-choice field, or a Number field into a Text field.

Change the field size.

For example, you cannot change the size of a text box from 20 to 30.

Delete certain fields. Some fields, such as Owner, State, and Progress, cannot be deleted.

When you generate a Web view, you can choose not to include specific fields. So even if you cannot delete them, you can remove them from all views. Of course, the fields will still take up space in your database.

Use multi-choice lists in workflow rules.

Use multi-choice lists in formulas, charts, or cross-tabs when building custom reports with Crystal Reports.

If you need to change the type or the size of a field, the best thing to do is to copy the field and delete the original. When you copy a field, you can edit its type and size. Note that copying a field does not copy the stored data, and deleting a field destroys any stored data.

What Happens to Styles

Styles such as queries and reports are based on fields. For the most part, HelpDesk Admin automatically updates styles when you customize the fields, but there are some exceptions.

When you add a new field

Current Issue - Detailed

Used to print the current issue in a Web view.

Notification - Detailed Record, Notification - Summary

Used to format the contents or attachments to e-mail notification messages.

In a Web view, these reports show only the fields exported to the view.

When you rename a field

When you change the label appearing on choice lists, HelpDesk Admin automatically updates any reports and layouts that use the field name as a title.

If you change just the Field Caption label, HelpDesk Admin does not update any reports and layouts that use the field name as a title.

If you rename a field such as the Progress field, you may want to rename any sorts, queries, and layouts whose names are based on the name of the field.

When you edit a choice list

If you delete a choice from a choice table (for example, Assigned from tblSubstate, the Progress choice table), then you have to update any queries that test the choice value. The same is true if you change the choice text (for example, from “Assigned” to “Started“).

You may also have to update custom reports that use the choice list. For example, when you change the choice text, custom reports that use a specified sort order will lump the new choice into the Others category.

When you delete a field

Custom reports that use the deleted field will not display properly. For example, if a custom report uses the field for calculations, or as a chart axis, then deleting the field invalidates the report. In many cases the report will still work, but the data it displays won’t make sense.

Creating Groups and Granting Permissions

Overview

If you want to restrict access to Web views or to administrative features, you use groups. Typically, you create groups that match the different roles in your help desk process. For example, if you have separate groups for employees and for help desk staff, you can prevent employees from opening the same Web views used by the help desk staff.

Enterprise HelpDesk includes several built-in groups that cannot be deleted: Users, Admins, and Guests. It also includes several sample groups that reflect basic help desk roles: Employees, HelpDesk-Analysts, and HelpDesk-GroupLeads.

If a help desk analyst is responsible for administering the Enterprise HelpDesk system, you can make the analyst a member of both HelpDesk-Analysts and Admins. As a member of Admins, the analyst has full access to all administrative features.

You could have several different admin-type groups, with each group providing a different level of access to administrative capabilities. For example, you might want a basic-level admin group that allows members to create new user accounts and update contact information. Other admin groups could provide the ability to:

Create fields, edit choice lists, rename tabs, change workflow.

Create reports, queries, sorts, and layouts, define notifications.

Create projects, delete records, perform database maintenance, set up notifications.

About the Built-in Groups

Users

By default, all users are members of the Users group. You cannot remove users from the Users group, or delete the Users group.

You use the Users group to set permissions that you want to apply to all users.

Permissions granted to the Users group are inherited by all users, and cannot be overridden. For example, if a feature is enabled for the Users group and disabled for Employees group, then members of the Employees group can still use the feature.

The reverse is not true, however. If a feature (or project or view) is disabled for the Users group, members of other groups can still access the feature (or project or view)—if you enable the feature (or project or view) for the other groups.

Admins

Members of the Admin group have complete access to all projects and administrative features. You cannot disable features or projects for the Admins group.

Guests

Intended for users who are not full-time employees, such as customers or visitors from other companies.

Features

Who can use the Ad-hoc Query Editor, generate reports, update contact information, view revision histories, or change their password in a Web view.

Who can log on to HelpDesk Admin, HelpDesk Web Admin, and the Web View Editor.

Who can use certain tools in HelpDesk Admin and HelpDesk Web Admin. For example, who can edit workflow rules in HelpDesk Web Admin, and who can create reports or edit fields in HelpDesk Admin.

Projects

When you create a project, you specify which groups can open the project. Groups allowed to open a project can:

Log on to Web views of the project (if they also have permission to open the view).

Edit the project in HelpDesk Admin.

Edit views of that project in Web View Editor, or generate new views of that project.

Admins can always open a project. Instead of allowing Users to open a project, you should allow specific groups. That way you can grant access permissions to views on a group-by-group basis in the Web View Editor.

Views

Groups allowed to open a view can log on to the view. A group must be allowed to open the project before it can be allowed to open a view.

Remember that if members of the Users group are allowed to open the view, then any user can open the view.

Creating User Accounts

About User Accounts

You need to create a user account for each person who needs to log on to a Web view or to one of the administrative tools: HelpDesk Admin, HelpDesk Web Admin, and the Web View Editor.

You don’t necessarily have to create user accounts for every employee in your company. If you provide a submit-only Web view for employees to use when submitting issues, employees don’t need their own user account.

Submit-only Views

A submit-only view allows an unlimited number of users to submit issues. All you need is a single user account. All users will automatically log on to the view with this account (in fact, the users never see the logon window, they go straight to the view).

This user account must belong to a group that has permission to open the Web view, and to add and update contacts. The account will be used to set the Submitter field.

The user submitting the issue is considered the contact, and must enter their contact information (name, e-mail, and so on) the first time they submit an issue.

Predefined User Accounts

Enterprise HelpDesk includes several built-in users: demo, guest, and admin. It also includes several sample users that reflect basic help desk roles: employee, analyst, and group leader.

You can disable most of these accounts in HelpDesk Web Admin. The admin account cannot be disabled, so you should change the admin password.

Disabled user accounts are still listed in the Contact, Owner, and Submitter lists. Deleting the users from the database (or removing them from the choice lists) requires editing the project database files.

Generating Web Views

Timestamping fields?

If your new project includes any timestamping fields from the base project (such as the Description and Description Log fields in the HelpDesk project), then you must manually update the Html code after control attributes of these fields.

Customized files from the base project?

New projects automatically inherit the customized Web view files of the base project. For example, all projects based on the HelpDesk project inherit the HelpDesk custom reports.

What if you don’t export a field?

Queries

If you don’t export a field, then don’t export queries that reference the field. The query won’t work.

For example, suppose you don’t export the Owner field, but you do export a query like My Open Issues, which tests the value of the Owner field. When a user tries to run the query, the user gets a message saying that the query could not be completed and the view is rolling back to the previous query.

If the query is the default query for the view, users will get a more informative message when they log on.

Layouts

Sorts

Listing Reports

Listing reports (such as the Current Issue - Detailed report, which is used by the Print button) include only the fields exported to the view.

Custom Reports

Like listing reports, custom reports include only the fields exported to the view. However, unlike listing reports, custom reports cannot always handle missing fields properly.

For example, if the Owner field is not exported, then instead of showing owner names along one axis of a chart, the report may show the summary descriptions or the priority values. What the report shows depends on the order of the fields in the report definition (if a field is missing, the next one in the definition is used).

Automatically update choice lists?

If you expect to frequently update a choice list, you may want to set the Automatically Update List attribute to Yes.

This means you won’t have to regenerate the Web view every time you update the list. The view will check for updates each time a user logs on.

By default, only the Contact, Owner, and Submitter choice lists are automatically updated.

Automatically updating a large number of choice lists may affect performance. You should automatically update only the choice lists that you plan to frequently change.

Do you want to change a field caption?

You can change field labels by setting the Caption attribute in the Web View Editor. This allows you to override the label specified in the project. For example, if the original labels assumed the users were help desk staff, you may want to change the labels in a view intended for employees.

The Caption attribute changes only the label displayed beside the field in the HTML form. Everywhere else in the Web view (such as in reports and the Ad-hoc Query Editor), the label defined in the project is used.

When do you have to regenerate?

Add a new field or query to a project. Remember to move the new field or query to the Export to View list before you generate.

Change a choice list (for example, add a new choice, or change the text of a choice), unless Automatically Update List is set to Yes.

When you change any of the attributes for a field (such as when you set Automatically Update List to Yes).

Change the definition of a query, sort, or layout.

Define new sorts and layouts. All sorts and layouts are automatically exported to views of the project.

Create or edit reports.

Add a group to, or remove from, the list of groups allowed to open the view. You just have to save the view.

Enable or disable features.

Web view users must exit and log back on to see the changes.

How to control the layout of fields?

The order of the fields in the Export to View list determines the order in which they are laid out in the two columns of the HTML form. For example, here’s how the first six fields in the Export to View list would be arranged, if:

None of the first five fields are Memo fields.

Field 3 has Column Span = 2.

Field 6 has Column Span = 2 and CSS Class = MemoFieldWidth. (Memo fields automatically have Column Span set to 2 and CSS Class = MemoFieldWidth.)

Setting Up Notifications

Notifications allow you to alert help desk staff and employees when issues are updated. For example, you can:

Notify analysts when issues are assigned to them.

Notify analysts when employees update an issue.

Notify employees when issues are resolved.

You should try to keep the number of notifications to a minimum. Defining too many notifications for field updates can overwhelm users with e-mail, resulting in users missing important notifications. Use notifications for changes to critical fields like Owner, Progress, and Priority.