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.
Consider the following when designing wizards:
•Writing a Wizard Specification Document
•Identifying Wizard Flow and Page Transitions
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:
oIntroduction to Customization
•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.
