Designing Wizards

Last updated
Save as PDF

When designing a wizard, you must consider various scenarios that users may face when creating records. For example, you need to determine the minimum information that must be captured by the wizard to quickly create a valid record, which fields may be automatically prepopulated, and how object definition rules might conflict with the wizard.

You must also design the layout of individual pages, page components, and page order. You may be able to reuse existing blocks of fields used in custom object record screens or create new blocks for the wizard.

Prerequisites

To create a set of useful and effective templates and wizards, you must meet the following requirements:

Define your organization's business requirements and accepted practices.
Understand TeamConnect's object model, whose attributes are described in Object Model: Read This First and the additional related reference tables.
Understand template and wizard basics and the major TeamConnect components, such as sub- objects and related objects.
For details, see:
Write a wizard design specification based on your system design. It must specify custom fields, blocks, and so on, which need to be included in the wizard. For an example of this document, see the Wizard Design Specification Document Example table.

General Considerations

Use the following checklist to develop a general outline of the wizards you may need to create and what kind of information has to be collected:

Determine the possible scenarios that may take place when a user must create a record.
For example, in a legal department, a representative receives a call reporting a transaction. The representative attempts to create a Transaction record in TeamConnect. The appropriate wizard checks whether the user is a member of the Transaction Attorneys or Paralegal groups and preselects the wizard pages according to the type of information the current user is allowed to enter.
Identify the information that must be collected when creating a record through each wizard and whether child records must be created and prepopulated with dynamic or static values.
For example, certain wizards may assign a default category for the record, then create related records such as task, account, or audit-history records.
Decide how many wizards are necessary to account for different scenarios, for example, one complex wizard with multiple pages and page transition rules or several smaller wizards, with each taking care of a specific scenario.
For example, you may want to create separate wizards to collect transaction details depending on the specified categories, and separate wizards for different involved party roles or child records.

Once you have a general outline for the wizard, you might want to write a specification document detailing all the wizard requirements. If you decide to create more than one wizard, the best practice is to create a separate document for each wizard. See Writing a Wizard Specification Document for more details.

Writing a Wizard Specification Document

A wizard specification document details all wizard requirements by determining the following information for each step (page) of the wizard:

Object for which the wizard and any associated templates must be created.
System and custom fields, or blocks of fields, which capture the appropriate information that needs to be gathered.
Required fields as specified in the object definition, such as:
- The parent project field.
- Fields whose values are used in the unique ID or name patterns.
- Fields that are required by the rules created for the selected object on the Create trigger-- create rules are not triggered until the user reaches the end of the wizard, which is when the record is created.
- Required custom fields to be included in the object view, and so on.
  For more details on required fields, see Required Fields.
Additional fields necessary only in the wizard. For example, parameter fields might require the user to enter a Yes, No, or Unknown value to determine the next wizard page. Such fields are not saved or displayed in the resulting record. For details, see Defining Parameters.
Default values for certain fields.
Additional rules to ensure the needed values are entered through the wizard.
For example, if a user selects Yes in response to a wizard question, the user must make at least one selection from a set of later-displayed check-boxes. This requirement might be accomplished using a custom block or by creating a page transition rule that directs the user to an end page.
Error messages displayed for the user if a page transition rule is triggered.
Prompts to help the user enter information for the fields in the record.
The field order on each page.
Page transitions, including dependencies on the input from the user.

The following table provides an example of a wizard requirements specification document for an insurance claim.

Wizard Design Specification Document Example

#	Wizard question	Field type	Field label	Display in record	Wizard page component	Comments
1	What is the caller's first name and last name?	Text	None	No	Parameter	If the caller is a third party, an action must be written to add the names to the involved party record.
2	What is the caller's phone number?	Text	None	No	Parameter	If the caller is a third party, an action must be written to add the number to the new contact record.
3	Is the caller insured or third party?	Radio Button	None	No	Parameter	Insured or third- party values If Insured, go to #4 If third party, go to #16
4	What is the insured's policy number?	Search Module	Policy Number	Yes	System Field	This is the name or number of the policy.
5	When did the accident occur?	Date & Time	Date of Loss	Yes	Custom Field	This is the date of the accident.
6	Where did the accident occur? Location State	Text field List	Accident Location Location State	Yes Yes	Custom Field Custom Field	This is the physical location (for example, intersection of 5th and Main St.) Use State List lookup table
7	Did the accident involve an intersection?	Radio Button	None	No	Parameter	Yes or No Value If Yes, go to #8 If No, skip to #9
8	What Type of Intersection was involved?	List	Intersection Type	Yes	Custom Field	Default to No.
9	Did the accident involve traffic controls or signage?	Radio Button	None	No	Parameter	Yes or No Value If Yes, go to #10 If No, skip to #11
10	What Type of Traffic Control was involved?	List	Traffic Control	Yes	Custom Field	Default to No.
11	Please describe the accident.	Memo Text	Description of Loss	Yes	Custom Field	For example, the insured vehicle failed to yield right of way and made a left turn in front of claimant vehicle.
12	Are there any Area Risk Factors that apply to this accident?	Radio Button	None	No	Parameter	Yes or No Value If Yes, go to#13 If No, skip to#14
13	Indicate the Area Risk Factors that apply to this accident.	Check- Boxes	Multiple - Area Risk block	Yes	Block	A rule must be added to require at least one selection.
14	Additional required information

Whether to Use Templates

Templates define what values are automatically populated for each type of record and what related records are automatically created. You may create wizards in association with a template or independently of a template.

Note: The information listed in your wizard specification document helps you decide whether using a template is worth the additional effort (see Writing a Wizard Specification Document).

If any of the following conditions exist, you must create a template for your wizard:

Sub-objects that need to be added to the record. For example, you need to add sub-objects if you are:
- Using custom fields of a category other than root in your wizard
- Setting a certain non-root category, such as Lawsuit, as a default category for all your records created from the wizard
- Adding several assignees to the record and setting one of them as the main one by default
Fields that may be automatically prepopulated in every new record, such as the Default Category or the Main Assignee.
Related records that need to be automatically created together with every new record, such as tasks or accounts.
You may create separate templates for associated records, such as accounts or invoices.

If you only need to prepopulate individual fields that do not require sub-objects, such as descriptions, dates, number fields, and so on, they may be prepopulated with the help of simple actions in the wizard itself without the need for a template.

Designing Wizard Layout

Once you specify the information that you want to capture, you may design the layout of your wizard.

Organize the fields and any questions into separate groups as you would expect them to appear in each page of the wizard, such as the following example:

Tip: If necessary, you may add wizard prompts to wizard pages as a component of the type Text.

Through the process of laying out page components, you may gradually determine the contents of each page, such as individual custom and system fields, blocks, text, or parameters. For more details, see Defining Page Components in Wizards.

Through this process, you may decide to create new custom blocks for certain wizard pages.

Tip: You may reuse the blocks created for object views of the object for which you are creating the wizard, or create new custom blocks for wizard pages, for example, to include parameters in them.

Identifying Wizard Flow and Page Transitions

After you have decided on the page layout, you need to make sure the pages appear in the appropriate order to the user creating a record. Plan your page order as follows:

Finalize the general flow of the wizard. Namely, define the sequence in which the wizard pages follow each other through page transitions.
For example, in the following diagram, an alternative sequence may result from Page 1 if the involved is a third party.
Identify the pages that require page transition rules and the qualifiers. These pages are marked by the diamond shapes in the following diagram.
Determine how many final pages may be required. These requirements include pages that allow the user to exit the wizard and pages that allow them to save the record, and dependencies such as missing information, limited rights, and so on. These pages are marked by the oval shapes in the following diagram.
Make a list of the page transition rules you have to create for page transitions based on the input data. You must:
- Identify the parameters used in qualifier items (conditions) for each rule.
- Identify the pages to which you want the user to be directed in each of the possible alternative flows.
  The order you indicate for the wizard pages, as you add them to the wizard, is always set as default order.