Validations determine the acceptable values for fields. They maintain data integrity by ensuring that the correct information is provided in a field before that value is saved to the database. For workflow steps, validations ensure the correct transitions are associated with the correct workflow step.
Validations are defined for each workflow step found in the Workflow Step Source window from which the step is derived. Figure 3-12. Workflow step sources and validations shows the Decisions window of the Approve (One User) decision workflow step validation. The validation for this workflow step validation is WF - Approval Step.
If you open the WF - Approval Step validation, (on the Decision tab in the Decision window, click Open), you can see that steps derived from this workflow step source can have one of two valid values: "Approved" and "Not Approved".
After you add an Approve (One User) decision step to a workflow, and you add a transition to the next step, the Approved and Not Approve values are listed in the Specific Results list in the Define Transition dialog box. (See Adding Transitions Based on Specific Results.)
There is a correlation between the validation and the execution type. For data-dependent transitions (token, SQL, PL/SQL), the validation must contain all possible values of the query or token resolution. Otherwise, the execution step could result in a value that is not defined for the process, and the request or package line could become stuck in a workflow step.
For most built-in workflow events and executions that run commands, the validation often includes the standard workflow results (Success or Failure). If the commands or event execute without error, the result of Success is returned, otherwise, Failure is returned.
Table 3-4. Relationship between validation and execution types summarizes the relationship between validations and execution types.