Wizards Overview

Wizards provide a powerful way to gather user input and help your users quickly and efficiently accomplish many different tasks within Service Manager. The Service Manager applications include many out-of-box wizards, and the Service Manager tailoring tools include a Wizard creation tool that enables you to design and build your own custom wizards that can be called from the various Service Manager applications and modules.

Prerequisites

Using the Wizard tool requires a solid understanding of the following areas, which are covered in other parts of the Service Manager tailoring documentation:

• Designing and creating forms
• Using the syntax of the Service Manager system language
• Performing traces for debugging purposes
• Creating processes and using the Document Engine

About creating a wizard

The Wizard tool enables implementers and administrators to add wizards within Service Manager that assist users with certain tasks, such as adding contacts to a database, escalating a Service Desk record to the applicable Service Manager module, and creating a new configuration item type for Configuration Management.

Functionality in a wizard record can include any or all of the following functionality:

• Creating records
• Selecting records from a database
• Modifying the current record
• Executing expressions (RAD or JavaScript), processes, and format control
• Asking for user input
• Stacking wizards to run in succession

You may find it helpful to review the embedded, out-of-box wizards. These wizards offer a variety of functionality, such as:

• Create a User (the User Quick Add Utility)
• Escalate an Interaction
• Reject a Change
• Add a CI Type
• Add a Contract

You can view these wizards by clicking Tailoring > Wizards, and then clicking the Search button.

In addition to simplifying repetitive user tasks, Wizards are very useful for processes that require the user to supply prerequisite information. For example, during the interaction creation cycle you could present a wizard panel flow for the operator to enter data. Based on how the caller replies to questions regarding the problem, the wizard determines which panels the operator sees next. While the wizard is executing, the operator-entered data may be accumulated in a file variable that is returned to the calling application when the wizard is complete.

The wizard can display a form and execute a Format Control record or process. The instructions in the Format Control record where there is a condition on “initial” that evaluates to true will be executed before the form opens. The instructions where there is a condition on “add” that evaluates to true will be executed after the user clicks OK.

Wizards are also very helpful when multiple complex decisions must be made in order to reach a conclusion. For example, Change Management approval requirement conditions are normally based on the data contents of one field in the change record. An example of such a condition is risk.assessment in $L.file="1." However, there may be circumstances where the approval requirement condition is based on the values of several different fields. For instance, there may be three fields that affect the approval requirements: division, area, and department. Hard coding all the possible combinations of these field values into condition statements requires a great deal of work and would be difficult to maintain. You can define these conditions in wizard records that do not display forms but that allow you to call a subroutine or execute standard Service Manager processing statements (similar to Format Control calculation statements). These options allow for the manipulation of record data. At runtime, the wizard acts as a decision tree that results in significant processing reductions compared to that involved in the original method of coding.

Wizard flow

Wizard flow defines the order in which wizard panels execute. Wizard panels can move in a straight line from start to finish, or branch into several different process flows.

The more complex wizard flows use condition statements that must evaluate to true before certain wizard panels can execute. If none of the specified conditions evaluate to true, the wizard flow is considered complete, and control passes back to the calling application.

It is very helpful to develop a map of the entire flow showing the name of the form (if any) displayed by each wizard panel and the conditions controlling the flow from panel to panel. You can follow the map throughout the wizard creation process to avoid simple errors that could prevent your wizard from operating properly.

Wizards versus scripts

Service Manager wizards have much in common with the Service Manager scripts utility, a legacy tool that has been part of the system tailoring utilities for many releases. Wizards go beyond scripting, enabling much greater functionality and flexibility.

A major advantage of wizards over scripts is security. Wizards are more robust and ensure data integrity, which scripts cannot do.

Unlike scripts, wizards allow you to specify the format control and display screen; you are not limited to the format control for a particular form, or to a particular display screen.

In addition, wizards themselves can call Format Control records and processes. Wizards do not allow direct calls to RAD applications.