Helpdesk Administrator Guide

This explains how to set up and administer the new Kyndal Helpdesk (version 1.4.2). How to use the helpdesk application is described in the User Guide. For more technical detail, see the Programmer Guide.


About the Examples

The helpdesk system is web-based, so the user interface is the browser window. The actual appearance will depend on what browser is used, the window size, what screen fonts are available and so on. Therefore the examples in this user guide won't necessarily look exactly like the real pages, although in many cases the HTML for an example was based on the corresponding page of the helpdesk.
Examples will usually be shown like this, with links like this and

Individuals whose names appear in the examples are fictional, although there are probably many thousands of real people with the same name.

The Admin Menu

The Admin menu has links to pages where the various tables controlling the behaviour of the helpdesk can be maintained.


This is where administration tasks are carried out.

Priority Code Admin

Category Code Admin

Questions and Answers

Contact Admin

Team Admin


Database consistency checks

To add a new request category (for example) you would go into Category Code Admin. You would probably also add questions and answers the helpdesk operator could use to diagnose a request as being in that category, and go into Team Admin to add the category to the skill set of one or more teams.

To add a new helpdesk operator, specialist, or other person you would use the Contact Admin page. If they are to belong to a team, go into Team Admin also to add them to a team or create a new team for them.

Priority Code Admin

Priority is primarily a measure of urgency not importance.The reason for this is simply that urgency can be quantified whereas importance is more subjective. Rather than an arbitrary numeric scale of "priority levels" which are ambiguous, I thought it was better to have named urgency levels with clear meanings.

For this reason, the default set of priority codes begins with (in decreasing order of urgency) "Critical", "Deadline", "No Deadline". "Critical" means "do it now", "Deadline" means the date by which it must be done is known, and "No Deadline" means "do it whenever you get round to it".

Other levels that are less urgent are possible. For example "Suspended" for tasks that can't be done yet but should be reviewed at a later date to see what can be done with them. Each priority level is associated with a date name, which defines how the due date is described for each priority level. So "Deadline" tasks have a "Deadline" date, whereas "Suspended" tasks have a "Review" date.

Priority Code Admin

CodeDescriptionDate Type (if any)
 C Critical
 D Deadline RequestDeadline
 N No Deadline Request
 O ObjectiveReview
 P Professional DevelopmentReview
 S SuspendedReview

To add a new priority code, enter the code, description and date type in the form at the bottom of the list and click the "Add" button. To edit the description or date type, click the link in the first column (the priority code).

Note that priority codes are sorted in alphabetical order. This is not a coincidence; it's how the system knows which is more urgent. Although the initial letters of the description have been chosen for the priority codes, they needn't be, as long as the codes sort in the right order.

Editing Priority Codes

Priority codes can be changed in the "Edit Priority Code" page. If no requests exist with that priority, there is a "Delete" button too, otherwise it looks like this:

Priority "D"

CodeDescriptionDate Type (if any)
D Requests exist

Category Code Admin

Requests submitted to the helpdesk get categorised so that they can get assigned to the right person, or if they are diagnosed as a problem with a known solution, the helpdesk operator can provide advice immediately.

Depending on how your organisation operates, you might want a knowledge base of hundreds of well-defined categories each with advice for its resolution, or you might want a few general categories just for your statistics. You can do either, or mix and match.

The category admin page looks like this:

Category Admin

+ AAS400
+ CChange to a system
- EError message or fault
+ ECError - PC crash or hang
+ EEE-MAIL Problem
+ HHardware
Code Description Usual Priority Team

Note: I strongly recommend that you keep one category with an empty category code, for uncategorised requests.

If you have a hierarchy of categories i.e. a general category and a set of more specific ones, it might be a good idea to use category codes that make it clear that they are related. For example, make the general category code be a prefix of the more specific ones. It helps later on when defining the skill sets of teams, as you will be able to match a team to several related categories with a wildcard pattern.

The categories are displayed in a tree, with the assumption that they are arranged in a hierarchy as described above.

To add a new category, enter its code, description and usual priority (see Priority Admin), and choose a team which will have that category as one of its skills.

By following the link on the category code in the first column of the table you get to the "Edit Category" page.

Editing Categories

The example below shows the various kinds of information that can be associated with a category of request.

Category "EP"

Usual priority:
Link to more advice:
Change category code:

Category Properties

MenuOptMenu option6User
MessageError message40User

Every category has a descriptive name, and a usual priority. Certain things are inherently crirital, others are usually not urgent at all.

Every category can have some "advice", which is text that will be shown when the request's category is identified. This is a good place to put advice such as "turn it off and back on, that usually fixes it", which might provide immediate resolution of a problem without assigning it to a specialist. There is also space for an advice link - a URL pointing to more information than can be entered in the "Advice" text.

There is an Update button to write back the changes. There is a Delete button to remove the category, unless requests of that category exist, in which case "Requests exist" appears instead.

Certain problems always require information to be gathered before they can be fixed, or you might want to always record machine serial numbers (for example) so that repeated problems with the same machine can be highlighted. Category properties are the way to do this. They are properties or attributes of the request that you expect it will be useful to record. Every category can have as many "properties" as you like. When a request is raised, it gets a copy of the list of properties which can be filled in for later reference.

It is possible to change the code used for a category. Enter the new code in the "Change category code" box and click on the "Change category code" button. All requests of that category will be changed to the new code. Request properties and team skills (see below) will also be changed accordingly. Note that only team skills that match the category exactly will be changed. Note that the questions and answers used to categorise requests are not changed, so any answers leading to the old category code will need to be changed separately.

Questions and Answers

To make sense of the system of categories, and provide a way for problems to be diagnosed as fully as possible while the call is being taken, a set of questions and answers can be provided which the helpdesk operator will use as a guide to selecting the correct category.

This can be a single question with a list of the few categories used as answers, or an expert system with many questions and answers that can be used to troubleshoot the problem extensively.

The questions and answers are maintained in a similar way to the eay they are used in diagnosing a problem. Starting at "Uncategorised", the administrator can choose answers to questions to navigate to the point in the question and answer tree where changes are to be made.

Such a question and answer page might look like this:

Questions and Answers

Guess State = ""(Category "Uncategorised")

1) What kind of request is this?

The "guess state" is shown at the top of the page. If it is a category code, then the category name is also shown. It needn't be, though. The guess state is just a string associated with the last answer that was chosen, so it need only be a category code when the answer chosen provided enough information to identify a category.

Choosing one of the answers changes the "guess state" and presents the next set of questions (if any). Another question can be added by typing in the field at the bottom of the page and clicking the "Add Question" button.

Choosing the link on a question takes you to the "Edit a Question" page.

Editing a Question

The text of a question can be changed in the "Edit question" page. If there are no answers defined for the question, it can be deleted.

Possible answers to the question can be added using the form at the bottom of the page. Note that the order in which the answers are specified doesn't matter. Each answer should be associated with a guess state - the best guess at the category of the request if that answer is given, or at least a new state which will have questions to further refine the guess.

Question 1

Guess State = ""(Category "Uncategorised")

AnswerNext guess stateCategory
Request for change to a systemRC Change to a system
Login troubleL User having difficulty logging in
Request for data extractionRD Extract data
Admin or repair of data on a systemRA
Admin or configuration of Unix systemU Unix systems admin
Request for a new programRN Request for new program
Error message or program failureE Error message

Note that there is no built-in consistency checking - the method is as flexible as possible which means that to use it well requires a bit of design effort in choosing useful categories and questions.

Contact Admin

The Contact Admin page allows contacts to be created. A contact is any entity needing a name, phone number, e-mail address etc. This certainly includes users of the helpdesk system and their customers.

Users of the helpdesk wanting to receive e-mail notifications when requests assigned to them are updated must have a corresponding contact record with an e-mail address.

Any contacts that are to be users of the helpdesk can be made so by clicking the "Make Operator" button, which will create a Zope user with the same ID. To give a user Admin permissions, you have to use the zope management interface - users created within f2w are only normal helpdesk operators.

Team Admin

A team is a set of users with a shared set of skills (as request categories they can probably handle). Teams can have a leader, although the team structure is purely skill-based and need not have any relationship to a management structure (e.g. teams can overlap). Every team has a unique ID and a descriptive name.

Team Admin

TeamTeam NameTeam Leader
 IT IS departmentmarwi
 prog Programmerspetha
 unix UNIX adminberdu

Teams can be added using the form at the bottom of the page. Following the link on the team ID, you get to the "Edit Team" page.

Editing Teams

Team "prog"

TeamNameTeam Leader

Team Members


Team Skills

Uncategorised (1 match)
DDocumentation (1 match)
RAMRepair or admin of data on MFGpro (1 match)
RC%Change to a system (9 match)
ULLinux systems admin (1 match)
RN%Request for new program (1 match)

The team name and leader can be changed on this page. If the team has no members and no skills, then it can be deleted (there is then a Delete button on the page).

Members can be added to the team by entering their contact ID and clicking the "Add Member" button. Similarly for skills. It has proved to be useful to have a team called "Anybody" (or whatever), with an empty ID, containing all users. Then common categories like "Uncategorised" can be associated with the "Anybody" team. And don't need to be set up in every team for all users to be able to be assigned requests of that type.

Users not in any teams

A much-requested feature has been users with restricted access, usually for non-specialists who want to be able to use the helpdesk in a limited way. If you want to allow such users, create them as operators, but do not add them to any teams. Since team membership implies the ability to solve certain classes of problem, not being a member of any teams implies a user who is not a specialist. Mostly this just means someone who creates problems rather than solving them ;)

Team Skillsets

Notice the skills containing a '%' are actually wildcard patterns matching a set of related categories. The number of matching categories is shown beside the description of the first one that matched. The idea behind this is that there are general categories with more specific ones within them. In the example above the programmers presumably can change programs on more than one system. Rather than list each category, they have a pattern that matches all the "Request change to ..." categories, including the general "Request change to system" that includes them all. This is just for convenience, and you can associate each category to a team explicitly if you like.


Users can set their own preferences but there is no administration task related to them yet.

Database Consistency Checks

There are currently two reports to help check database consistency.

Reachable Categories

This report shows all guess-states in the knowledge base and all request categories, showing whether they are reachable by answering one of the diagnostic questions. It can be used to check that the questions and answers set up actually cover all request categories that have been defined.

Teams skilled in each category

This report shows all categories, and the names of all teams which are skilled in each. It is useful to check this when new categories have been added or the makeup of the teams has changed, to make sure any request can be assigned to someone who can actually help with it.

Still to Do

There should probably be more database consistency checks.

Any other suggestions are welcome.

Last changed 17 April 2002