On a request, field behavior can be linked to the status of the request. For example, a request cannot move to the Assigned status unless the Assigned To User field contains a value. In addition, as long as the request has a status of Assigned, a user cannot change the Assigned To User field.
To make this work, the Assigned to field is configured with the following settings for the Assigned status:
Visible = Yes
Editable = No
Required = Yes
Reconfirm = No
Clear = No
You configure field dependencies from the Status Dependencies tab in the Request Type window.
To assign field properties based on request status:
On the PPM Workbench shortcut bar, click Demand Mgmt > Request Types.
The Request Type Workbench opens.
Open a request type.
In the Request Type window, click the Status Dependencies tab.
From the Request Status list, select one or more request status values.
Note: You can use the
Ctrlkeys to select multiple values.
In the Field table, select the request field for which you want to configure properties based on the selected request status.
Under the Field section, set the options described in the following table.
Determines whether the field is visible to users while a request is in the selected request statuses. If this option is set to No, the field is hidden while the request is in the selected statuses.
If the Editable option for a request field is set to No for a specific status, then users cannot edit the field while the request is in that status. If the Required or Reconfirm option for a request field must be set to Yes, then the Editable option must also be set to Yes.
At certain stages in a request resolution process, you may want to ensure that specific fields are not changed. For example, when a request of type Vendor Bug has the status Patch Applied, you want to ensure that the Patch Number field does not change. To accomplish this, you set the Patch Number field to be read-only for all request statuses after a certain point in the workflow. (Of course, you would probably make the Patch Number field required in an appropriate previous status, to ensure that it has a valid value before it becomes a read-only field.)
Specifies whether the field is required or not while a request is in the selected request status(es). If a field is required when a request is in the selected status, a user must provide a value for the field before the request can move to that status. When the workflow transitions to the status, the "look-ahead" page is displayed to require the user to fill out the fields to be required for that status (if any of those fields do not already contain values).
If the Reconfirm option for a field in the request type is set to Yes, the field is presented to the user on the look-ahead page before the request is allowed to transition into this status. The user can review the field value and, if necessary, change it.
The Clear field is used in conjunction with other dependencies to remove the content of a field. The clear flag is used as follows:
If set to Yes, and either or both the Required and Reconfirm options are set to No, the field is not presented to the user on the look-ahead page, but the field is automatically cleared when the request moves to status.
If set to Yes, and either or both of the Required and Reconfirm options are also set to Yes, then the field is cleared and displayed on the look-ahead page as the request is moving to this status. If required, the user must provide a valid value in the field before the request can complete the transition to the new status. If only reconfirming, then the user can decide whether or not to provide a value before continuing.
Note: To present the Reconfirm field to the user for mass update of records, set the Clear field to Yes.
You can configure multiple fields simultaneously by using the
Shiftkeys to select the fields and then change the attribute values. You can also select multiple status values and change the same fields if those states require the same attribute values for the same fields.