Methods of data validation
When you design a view, you add all the fields and controls that the specification requires. You must also consider how to ensure that the data values generated by users are valid. Valid data is required so that the system can process the information without error. Some data requirements are outlined in the following table.
|The data must be the right type.||For example, users must enter a number in a Total purchase units field.|
|The data must be restricted to possible values.||For example, users can only choose a valid loan type by selecting the type from a list of options.|
|The data must fit the business logic.||For example, a Date of birth field must be in the past.|
To prevent processing errors, Pega Platform™ provides field types and controls to support validation requirements. Choosing the right control may be sufficient to satisfy a validation requirement. In cases where a control or field type is insufficient to perform data validation, Pega Platform provides data validation by using business logic to test fields with conditions. For example, you can use a calendar control to ensure that the data entered by users is a date, regardless of whether the format is dd/mm/yyyy or mm/dd/yyyy. But you cannot use a calendar control to ensure that a Start date field in an employment history form captures a date in the past. Instead, you can validate the date is in the past using business logic.
Business logic data validation
You use App Studio to perform simple business logic validations that compare the value of a field against a constant value when users submit a form. You create conditions that define invalid data values so that an error message is displayed when the condition is met. If users generate a value that meets the condition for an invalid value, the system displays an error message and prevents the user from continuing the case until the issue is resolved. For example, you want users to enter a value greater than 100 in the Enter digit greater than 100 field. To configure the validation, you create a condition that states Enter digit greater than 100 field is less than or equal to 100. When users submit the form, the system evaluates the condition based on the value in the field. If the condition evaluates to true, meaning the value in the field is less than or equal to 100, then the message is displayed on the form.
Tip: Your error message should provide users with the information needed to identify and resolve the data validation error.
Business logic validations are often associated with processes in the case life cycle, enabling you to validate each field instance based on distinct business logic validations. The business logic validations that define acceptable values are separate from the fields that capture data. For example, a Date of birth field is validated when users enter the date on the field. The validation is not applied again when the field is used later during case processing.
Multiple forms may use the same field and apply different validation conditions for each instance of the field. For example, in the HR App, HR representatives enter information in two forms, the Job History form and the New Hire form. In the Job History form, an HR representative enters the start date of an employee who already works at the company. The HR representative must enter a date before the current date. In the New Hire form, an HR representative enters a start date for an employee who has not started work. The HR representative must enter a start date after the current date. Using two business logic validations, one for each business condition, you can ensure that the correct dates are entered on each form.
In App Studio, you can validate the value of a field when you submit a form or when the case enters a stage.
Check your knowledge with the following interaction.
Validation on a form
You use business logic validations on a form when you cannot predict or control the value that users enter. You configure business logic validations on a form, and the validation is triggered when users submit the form. If users submit a form that contains a value that meets the condition for invalid data, the form displays an error, and the system prevents the users from continuing the case until users submit data that fails the condition. Use validation on a form when users can perform an immediate action to resolve the invalid data, such as entering a new value in a field.
For example, assume a form contains a date of birth field. The field type and control cannot prevent users from entering and submitting a date that is in the future. However, you can design a business logic validation to display an error if users submit a date that is in the future. The form can be submitted once users enter a date in the past.
In the center of the following image, slide the vertical line to view the step configuration to validate the Date of birth field on the left and the error message that is displayed in the form on the right.
Validation on a stage
You can also use business logic validation on a stage. Use business logic validation on a stage to ensure the application has generated the correct data and that users have entered the correct data or performed the appropriate actions before the case enters a specific stage. You configure business logic validations on a stage in the case type data model, and the validation is triggered before the case enters the specified stage. On a stage entry validation, if a data value meets the condition for invalid data, the case cannot enter the stage, and an error message is displayed.
Note: When an error message is triggered on a stage validation, end users need to have the ability to update invalid data or perform an action, such as returning to a previous stage or closing the case. It is up to the developer to configure the functionality that allows end users to resolve the validation error.
For example, in a mortgage application, a valid credit score must be available before the case can enter the underwriting stage. The application informs the user that the credit score is invalid, and the user is allowed to verify the credit history on file or cancel the process.
In the following image, click the + icons to read more about configuring validations in the case type data model.