Version 4.51(5.0) Enhancements
With Support-Works Helpdesk Professional, Hornbill Systems Limited introduces
a unique and refreshing approach to helpdesk technology. Support-Works
has been developed over five years and the original concepts of increased
performance, ease of use and lower cost of ownership have been maintained
through to the latest release. This white paper describes the high-level
architecture and conceptual model of Support-Works Version 4.51. It introduces
the new features provided by Version 4.51, and where appropriate, highlights
the differences between earlier versions of Support-Works Helpdesk Professional
Support-Works Non-Polling Architecture (NPA)
Support-Works Non-Polling Architecture (NPA) ensures that product performance
is unrivalled in the helpdesk market. Hornbill believes that Support-Works
is the only helpdesk product available in the market that will allow remote
analysts to connect using a standard Windows GUI and operate effectively
at speeds as low as 9600-baud. NPA also ensures rapid installation and
dramatically reduces implementation time and costs. In version 4.51 this
design has been further optimised for greater performance by reducing
the number of API calls made between the client and the server.
Support-Works products are developed entirely in Visual C++, ensuring
a robust and stable product. The Support-Works Helpdesk Professional server
is supplied with all the components necessary to implement a complete
helpdesk system. Support-Works Helpdesk Professional provides e-mail integration
and file attachment support for Internet Mail (SMTP/POP3/LDAP), Microsoft
Exchange, Lotus Notes and Groupwise. Service Level Agreement (SLA) management
with comprehensive escalation and notification options, Knowledge Base
and many other components, all shipped with the product as standard.
Support-Works Version 4.5 and above is also supplied
with an SQL database server. This database includes an ODBC driver so
access to your data can be achieved with any other third party application
that is ODBC 2.5 (or better) compliant. This does not in any way preclude
the use of a corporate database server such as Oracle, Sybase or MS SQL.
In-fact, the Support-Works architecture is designed to operate with any
SQL database that provides connectivity via ODBC 2.5 (or better). Other
server components include a Knowledge Base server, Index server and HTML
Support-Works products have always been built around a Microsoft Office
'look and feel', complete with drag 'n' drop, dockable toolbars etc. to
promote familiarity with the interface. Versions up to and including 4.5
have presented static forms that are directly related to the underlying
database schema. The look and feel of this interface has remained consistent
with the published Microsoft Guide to GUI Design. One primary objective
of the design of version 4.51 was to maintain 100% backward compatibility
with version 4.5 of the product. Considering the fundamental difference
between the two versions (static schema Vs dynamic schema), this was a
difficult task. The goal was to ensure that, when a customer upgrades
from 4.5 to 4.51 there will be no re-training required for their users
to continue using the software. This will allow existing customers to
take advantage of new features offered in 4.51 immediately. The appearance
of some GUI elements have changed considerably, but the default configuration
as shipped with the new version has been pre-configured to emulate the
previous behaviour of Support-Works.
Support-Works Version 4.51
Support-Works Helpdesk Professional Version 4.51 is due for release in
Oct/Nov 2000 and delivers complete user customisation. Hornbill resisted
adding extra fields to tables to get by with partial customisation. Instead,
Hornbill has developed 'Adaptive Server Technology'. This simply means
the internal data structures adapt to the schema of the underlying
database at runtime. An example of this would be a table that represents
a customer table. On version 4.5 this table is called userdb. As
long as the table meets certain criteria, the customer table can have
any number of columns. Each column can be any data type (depending on
the SQL database in use). When this has been defined on the database,
the Support-Works server builds its internal data structures using the
information retrieved from the SQL table schema. In contrast, version
4.5 required the customer table (userdb) to have a set number of
columns of an exact data type. If this was not the case, the 4.5 server
would not operate.
There are two basic parameters that are available
from the SQL database for each column. The first parameter describes the
columns data type (e.g. Number, Text, Currency, Date etc). The second
describes the size, or maximum size of the information that the column
in question can hold. For example, a column that holds a telephone number
might be a Text column that has a maximum size of 20 characters.
This would be sufficient to hold any standard telephone number. While
these two parameters are sufficient for the database to do its work, an
application interface requires considerably more information about a column
in order to control and display user input for a given field. For example,
if an input field exists where the user can enter a telephone number,
we have enough information from the SQL database to limit the input to
the maximum size allowable by the database. However, it would be desirable
to configure many other attributes of this input field. For example, we
may want to limit the input to all numeric characters and only allow hyphens
for punctuation. Or we may want this field to be read only for some users
but read/write for other users. We may want to provide customised help
for this input field or mark it as a URL Link field. To complement the
basic column/table configuration, Support-Works Version 4.51 introduces
'Active Data Dictionaries'. An Active Data Dictionary simply augments
the configuration information held against each column in each table and
allows many more parameters to be defined as part of the configuration
process. The 'Active' part of these data dictionaries describes how the
Support-Works server dynamically merges the basic database schema from
the SQL database with all Active Data Dictionaries on the system.
Data Dictionary Editor showing the typical properties
of a table column. It can be seen from this screen that many more parameters
are available for each column and include input masking, display name,
default value and help text.
The client side application uses the information
stored in the data dictionary to define and control the behavior of the
GUI elements when the user is viewing or inputting data. It is also possible
to have more than one data dictionary on the same system and assign different
users different data dictionaries. In effect, you could have very different
behavior between different users on the same system. A common example
of this would be to provide field names and help text in different languages.
Or different support groups could have different levels of access to individual
Elements of the Data Dictionary
The data dictionary offers extended attributes to table columns as
seen above. Although this adds considerable additional functionality over
and above a static schema system, this functionality alone would be somewhat
limiting for a modern business application. We have defined a number of
additional elements that make up the Support-Works data dictionary and
customisation framework of Support-Works.
- EasyForms - These objects are a form definition
that will allow browsing and inputting of data for a single database
record. The key benefit of EasyForms are their layout is automatic and
is based on the column configuration and settings.
- LayoutForms- These objects are a form
definition where you can design the actual layout and placement of GUI
components. (LayoutForms will not available until Version 5.0 of Support-Works
is released. Target date is Q1- 2001).
- TableBrowsers - These objects define a
form that will allow browsing of a table (with or without filters applied)
- PickLists - These objects are similar
to TableBrowsers but define a form that will allow the selection of
a single record from an ambiguous search enquiry.
- ImageLists - These define lists of Icons/Images
that can be associated with data to visually represent types of records.
For example, an icon of a PC could represent a Hardware PC asset, a
picture of a CD could represent a software asset and so on.
Database Dictionary Editor
The Data Dictionary Editor enables complete customisation control. The
editor allows several views to be created on database information. Forms
can be created according to the requirements of different groups or analysts.
These forms can define which columns from a given table will be active
within the form. Each field in the form will inherit the parameters defined
in the database table, so a consistent input and display operation will
be achieved. Many options may be defined for each field, including the
ability to display or hide fields, define input masks, mandatory fields,
and set distinct pick lists etc. according to the configuration of the
database dictionary in use.
Easy Forms can be created with a simple design. The form needs only to
be configured to include the form name, default size, the associated table,
visible and mandatory fields, pick lists, input masks and help text. An
example of an easy form would be 'Adding new Customer record'.
Tabbed forms may be created and defined in similar manner to easy forms.
As shown in the images below, several tabs may be added to the form. Each
tab can hold one of four classes of sub-forms. To allow the configuration
of an EasyForm, Related EasyForm, RecordList or NotesForm.
Layout forms have not been added to Version 4.51 but will be added in
version 5.0, providing full form design functionality similar to that
found in Microsoft Access or any other 4GL type database application.
Table Browsers can be created and bound to a table. Parameters such as
a filter, form title and Add/Edit record forms can be defined.
Action buttons can be defined on forms to generate
allowing the user to determine what actions are performed when the button
is clicked. Events such as 'on record open' can also be defined, forcing
certain actions when the record is opened. The appearance of the table
browsers has been graphically enhanced, allowing the user to select colored
grid lines, horizontal bars etc.
Pick Lists allow the user to define the table in which the pick list will
apply, the forms related, the visible columns and the help text.
Image lists enable different images/icons to be defined by the user.
Call Handling - The Log Call Form
It is now possible to define any number of log call forms, depending on
the requirements of each group or analyst. Furthermore, it is possible
to define additional log call forms which relate directly to the classification
of the call. For example, certain details may be required when logging
a 'hardware' call and other details required when logging a 'software'
call. The appearance of the form can vary according to the group or analyst
viewing the call details. Form backgrounds can also be defined by the
user. In version 4.51 the elements of the main components can be configured.
For example, fields can be added to the Customer/Contact details component
and configured for searching. New elements can be bound to the active
call table for inclusion into the call record. However, the 'layout' of
the form its self is static in version 4.51. Version 5.0 will provide
for form layout customisation. Another new concept is 4.51 is the call
class. The class of call defines the type of call. This is treated
differently to the call profile. The class of call allows you to configure
different classes of call. I.e. Hardware, Complaint, Software, New Sale
and so on. Each class of call can be used to control the properties of
the log new call and call details forms. The class of a call is stored
in the call database against the call, so when it is viewed, Support-Works
knows what form(s) to use to represent the call. For example, a complaint
call would have very different user interface requirements than that of
a PC Hardware call.
In version 4.5, the relationship between a call record and a customer
record was fixed. In version 4.51 the relationship between a call and
a customer now includes an additional table. The default configuration
of this table is for a contact, so the userdb table becomes the
company, the contact would become the individual. You can also set up
a one to many, one to one, or many to many relationship
between the customer and contact tables giving ultimate flexibility. The
fact that the userdb and the contact tables are named as
such is simply to maintain backward compatibility with previous versions
of Support-Works. These tables could equally be called customer1
and customer2. This enhancement means that Support-Works is now
very much closer to a 'General Purpose' helpdesk solution, where as historically,
Support-Works Helpdesk has had a bias towards the internal IT Helpdesk.
The same relationships that have been described in the 'Customer Details'
above, now also applies to assets. The table equipmnt which is
the original asset table is now complemented with a component table.
Again these are functionally equivalent to the two customer tables described
above and could equally be called asset1 and asset2.
Ad-Hock Customer Details
In version 4.5, the customer record was mandatory when logging a call.
In an environment where customer details were only applicable for the
life of a particular call, it would not be desirable to have to create
a new customer record to log a call. If we take an example of an ISP who
provides premium rate support to anyone using their free dial-up service.
When their customer logs a call, they would need to record their name,
telephone number and e-mail address. They would only need this information
until the problem is resolved so no customer record needs to be created.
In version 4.51 you can simply add these additional columns to the opencall
table and configure the log call form to use this instead of a related
customer record. This way there would be field validation (as enforced
by the data dictionary table configuration) but the details would be held
directly in the opencall table.
Call Profile Codes
Version 4.5 used a three-tiered hierarchical coding mechanism (user defined)
for classifying the type of problem being logged. Version 4.51 has no
restriction on the number of levels that may be defined. Depending on
the data dictionary and the call class, a different form can be presented
to the analyst and the level of call profile can be specified. To illustrate
this, take an example of an internal helpdesk supporting software applications.
The first line group may classify the call as:
Software - Microsoft products - Office 2000 - Outlook 2000 - E-mail. However,
the second line support analyst who is responsible only for Exchange/Outlook
problems would only need a profile which started at the level 'Exchange'.
This profile could look as follows: Outlook 2000 - Mail - Messages not
Call Class Defined Attributes
A further (optional) tab is added to the log call form, adjacent to the
File Attachments tab (not depicted in image above). This tab will hold
user defined fields which may be specified from a different table. The
table, and therefore the meaning of this additional information can be
selected depending on the class of the call. For example, a call logged
for a complaint about service may require a tab which detailed complaint
specific information like, incident, service person, event and so on,
whereas a call logged against a software problem may require information
such as version number, build number service pack, etc.
The call settings/options area will include information such as priority
and charge centre. Additional fields can be added as required.
Default priorities in Version 4.5 included 'Use
Customer Priority', 'Asset Priority' and 'Charge Centre Priority' as well
as the option for the analyst to override this priority and select any
other configured priority. Version 4.51 will include another default,
'Use Call Profile Priority'. This allows default priorities to be allocated
to each call type. For example, a server crash - high priority and a user
unable to log in - lower priority.
Version 5.0 enhancements
Graphical User Interface (GUI)
There are a number of changes planned for Version 5.0. The most significant
change is a new GUI. This new GUI is known as a Multi Top Level Interface
(MTLI), which means that each form is actually a new top-level window
that has its own toolbar and menu. A good example of this style of GUI
is Outlook 2000. This change in GUI will optimise the look and feel and
provide an appropriate interface for form layout customisation.
Internal Mail System
The Support-Works internal mail system will be completely re-written for
version 5.0. The new mail system will include multiple folders, such as
sent and deleted items etc, ability to add additional folders etc. Support-Works
currently only provides for one shared mailbox. Version 5.0 will allow
multiple shared mailboxes to be created. This will allow a single Support-Works
server to be used by several autonomous groups within the same organisation.
Although Support-Works 4.51 is only a minor numerical upgrade from version
4.5 it should be apparent that it is in fact a major upgrade. Much of
4.5 has been rewritten to accommodate the new dynamic database implementation.
Version 4.51 is a significant enhancement to our already popular product
and we expect this upgrade to deliver significant enhancements to your
business application requirements. Tailoring the application to more closely
meet individual business requirements will increase the effectiveness
and productivity of your support and enhance the level of service offered
to your customers.