Define request types
Requests are instances of request types. A request type defines the Web form that users see when they create or view requests of that type. Each request type defines the set of fields specific to that type of request.
Each request type definition also specifies which request header type to use. The request header type defines sets of standard fields that are common to multiple request types. The request header type includes options for enabling integration with other OpenText products, both within the PPM product suite (Program Management, Project Management, and Portfolio Management) and outside of the suite (such as Universal Configuration Management Database, Quality Center, and Service Center).
Different information is required to process each request. For example, to resolve a software bug, you might need to know the software unit, product version, problem, priority, and so on. The fields on the request type and request header type capture this information.
Before you create a request type, determine what standard fields are available for the request (request header types and field groups). The fields displayed in the Summary section of a request detail page (see Figure 2-1. Sample request) are derived from the request header type associated with the request type. The fields in the details section are defined in the request type itself. To see all fields in the details section, open the workbench and go to the Layout tab of the Request Type window.
For each request type, provide the following information:
-
Name of the request and request type
-
Request header type attached to this request
-
Fields to display on the request
-
Request status values, such as Pending, On hold, Approved, and Canceled
-
Notifications to send when the value of a selected field changes
-
Request-level access information to specify who is allowed to create, view, and edit requests of this type
-
Workflows that can be used by requests of this type
For each new field required on the request type (or the request header type), gather the following information:
-
Field label. Specify the field label to display next to the field in the Web form, to ensure that the correct information is captured.
-
Information type. What type of information must be collected? Is this a text field, a drop-down list, or an auto-complete field? The validation specified for a field determines this.
-
Field behavior. You can control many aspects of field behavior, including:
-
Whether (and at what point in the workflow) the field is editable, read-only, required, hidden, and so on. Both the workflow (process) and the behavior of other fields in the form can control field behavior. For example, you can configure a field to be required only when the request reaches the "Assign" status.
-
Whether the field is populated automatically based on values in other fields.
-
Who can view and edit the field, and who must be restricted from viewing the information in the field.
-
For more information about request types and request type fields, see Worksheets.