Controlling Request Field Behavior
You can control the behavior of request fields in PPM by setting up request type rules and status dependencies. Because these two methods of determining field behavior have functional overlap, they can produce unexpected results when used together. Therefore, it is important to understand what each does and how they can interact to propagate changes through the system.
Status dependencies can be used for status-based business logic. You can configure status dependencies to change request type field attributes (visible, editable, or required, cleared, and so on) whenever a request moves to a new status.
When a user acts on a request, the PPM system does the following:
The system looks at the workflow and computes the next status that the request would have as a result of the action.
Based on status dependencies configured for the next status, the system "looks ahead" to determine whether any fields are required or need to be reconfirmed for that status.
If status dependencies dictate that a field must be reconfirmed, or that it is required for the next status, and currently contains no value, then the user is directed to an intermediate page, which is referred to as the look-ahead page. The look-ahead page displays all required fields that are empty, and all fields that contain values that must be reconfirmed. The user must either provide the required values so that the request can transition to the next status, or cancel the action.
With status dependencies, a request can transition one way in a workflow to make some fields required, but transition a different way and make no fields required. In some organizations, users must complete specific required fields to cancel a request. The "look-ahead" functionality of status dependencies enables you to avoid this kind of complication.
For detailed information on how to configure status dependencies, see Configure request field status dependencies.
Request Type Rules
Request type rules are used to drive dynamic behavior of request fields directly from the request detail page, independent of status changes. This is often critical for ensuring the usability of complex request forms, and enables you to add advanced logic into a request to help guide the user, simplify data entry, and minimize misunderstandings.
You can use request type rules to define dependencies between fields, and use these dependencies to set default values in any field, show or hide specific fields, make other fields required or optional, change the styling of a field, and other dynamic behavior. Each request type can contain as many rules as necessary.
As an example, consider a request type designed to handle a project proposal process. Among the fields it contains are a Projected Cost field and a # Resources field. The request type also contains a Project Size field, which is to be used to qualitatively categorize a proposed project as "small" or "large," which the workflow depends on later in the process. Rather than forcing users to make a subjective judgement on what constitutes a "small" or "large" project, the Project Size field can be hidden and automatically defaulted with request type rules. A rule can be defined to set the Project Size to "small" if the Projected Cost and # Resources fall below specified values, and to "large" otherwise.
For detailed information on how to configure request type rules, see Request Type Rules.