Overview of Request Type Fields

Each request type field has the following three associated attribute criteria:

  • Criteria for visible fields

  • Criteria for editable fields

  • Criteria for default fields

The following sections provide information about these attributes and instructions on how to set them for your request type fields.

Criteria for Visible Fields

You can specify that a request type field be visible to or hidden from users. Table 5-1. Criteria for visible fields lists the methods you can use to do this.

Table 5-1. Criteria for visible fields

Criteria

Description

Field attributes

Use the Attributes tab in the Field window to designate a field as always visible or always hidden. For details, see Creating Fields for Request Types.

Request status

You can specify field visibility based on request status (linked to the workflow step). For details, see Configuring Request Statuses for Request Types .

Field security

You can use the Security tab in the Field window to specify field visibility for particular users or security groups. For details, see Creating Fields for Request Types.

Figure 5-3. Field visibility interactions shows how Demand Management determines field visibility for a particular user. In this diagram, the user is assumed to have permission to view the requests, which requires the correct license, access grants, and settings on the User Access tab in the Request Type window.

Figure 5-3. Field visibility interactions

Criteria for Editable Fields

You can configure request type fields to become read-only or editable based on request status or users and user groups. Table 5-2. Criteria for editable fields lists the methods you can use to determine field editability.

Table 5-2. Criteria for editable fields

Criteria

Description

Request status

You can specify that a field is read-only based on request status. For details, see Configuring Request Statuses for Request Types .

Field security

Use the Security tab in the Field window to designate fields as read-only for specific users or security groups. For details, see Creating Fields for Request Types.

Advanced UI rules

Advanced UI rules can be used to make a field editable or read-only, based on dependencies that have been configured. Even if request status and field-level security dictate that a user can edit a field, that user cannot edit the field if an advanced rule is triggered based on some other dependency that makes it view-only. For details, see Advanced rules for request types.

Note: You cannot use special commands to trigger rules.

Criteria for Default Fields

You can configure a field to automatically update the values in other fields. Table 5-3. Criteria for default fields lists the configuration methods you can use.

Table 5-3. Criteria for default fields

Criteria

Description

Field defaulting

From the Default tab in the Field window, you can link the value in a field to the value in other fields defined for the same entity. For example, a request type field can default to the username of a specific manager when the value in another field in that request type equals "Critical."

For details, see Creating Fields for Request Types.

Request type rules

From the Rules tab in the Request Type window, you can configure a request type to automatically populate one or more fields based on the values in the dependent fields. For example, if a field has the value "Bug Report," then the workflow, contact name, contact phone, and department can be automatically set by corresponding request type rules.

For details, see Request Type Rules.

Request type commands

You can use commands to control certain aspects of request type field behavior. You can specify that the commands stored in the request type be run at specific workflow execution steps in the resolution process. These commands can then manipulate the data inside a request type field.

For example, you can construct a command to consider a number of parameters, and then default a field based on those parameters. This provides an advantage over the defaulting features in the Field window, which can only default based on a single parameter stored in the same request type.

Using commands to control field values using commands can be useful for:

  • Storing a value from an execution (You can also use workflow parameters to do this.)

  • Clearing a field after evaluating multiple parameters.

For more information on how to set up commands to control field defaulting, see the Commands, Tokens, and Validations Guide and Reference.