View source for Applying validations to ensure data integrity

Applying validations to ensure data integrity / ← Apply validations to ensure data integrity

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in one of the groups: Users, editor, pegaemployee.
• The action you have requested is limited to users in one of the groups: pegaemployee, editor, Administrators.

---

You can view and copy the source of this page.

{{Design pattern |Title=Apply validations to ensure data integrity |Description=Applying various types of validations in an application |Version= 8.4 |Applications=Pega Platform |Capability Area= Low-Code App Development |Owner=Bhowmick, suman}} While collecting input from Pega Platform™ users, validation helps ensure proper data is entered by users. This is critical for successfully processing cases. Validation is one of the most important parts of application development, because it helps the end user understand where they went wrong and how they should correct it. Pega provides various types of validations which can be used based on the need. Below are the different types of rules associated in Pega: * Validate rule * Edit validate rule * Constraint rule * Through the property rule * At section rule '''The most important rule of validations: keep validation out of the UI layers''' One of the important best practices related to validation is to keep it out of the UI layers. It may seem easier to keep the validation at the control level but it makes it harder in the future. Validations that are embedded in the UI layer don't work when a case is processed through other channels such as APIs, conversational channels etc. Avoid this mis-step by keeping validations out of the UI layer.<div> == Determine the type of validation to use == It is important to determine the correct type of validation to use for a particular context. While defining validations for your Pega application ask the following questions to determine what type of validation to use: *Is this validation needed for a field at every place its used? - use ''field validation'' *Do you want to apply a validation for a field which is calculated from other fields? - use a ''constraints rule'' *If a particular validation is needed only in a form while entering data? - use ''form validation'' *Do you want the user to stop entering a stage when few fields are not captured?  - use ''stage validation'' *Do you want to validate same conditions each time while saving a case?  - use ''validation on case save'' *Is it needed to apply some validation before creating a case? - use ''validation on case creation'' ==Field validation== If a validation for a field is applicable at each and every place where the field is used in the application, use field-level validation. The most common field-level validations are taken care of automatically when fields are created from App Studio.  When user creates a field of below types, field-level validations are automatically added. Email URL Phone For an email type field, if the input value is not in proper email format, an error is shown. Similarly, for URL and phone type fields, unless a value with proper format is entered, error is shown at run time. User doesn’t need to do anything explicitly for this. If user wants to add restrictions like max length for text fields, it can be added at the property rule. With this user won’t be able to add more characters than what’s defined while entering value for that field in the form. If user need to add some other field-level validations, user can create, or reuse Edit validate rule and associate with the field rule. Edit validate should be used only for format limitations or value range limitations. It should not be used for comparisons of one field against another, because edit validate rules are client-side validation and the other inputs may not be available at the time the edit validate rule executes. To learn more about Edit validate rules, see [https://community.pega.com/sites/default/files/help_v84/express/procomhelpmain.htm#rule-/rule-edit-/rule-edit-validate/related.htm More about Edit Validate rules]. == Constraints rules == All the field-level validations we saw so far, are useful where we want to put some validation for a field, where an end user enters a value. But there could be a scenario where the value of a field can be calculated from other fields which might be entered by user. There is another way to validate a field declaratively, whenever its value changes. It can be done by creating a Constraints rule. Any time the specified field value changes, the Constraints rule checks to confirm that the value still falls within the expected range. This validation should not be used for fields which are simply entered by the user, but rather for fields that are computed from different fields which might be entered by the end user. To learn more about Constraints rules, see [https://community.pega.com/knowledgebase/articles/application-development/84/about-constraints-rules About Constraints rules]. == Form validation == When designing a case type, it's critical that a form meets all the required conditions before the form is submitted and the case moves to the next step. By validating the values of various fields in the form, application developers can ensure that at run time correct data is entered by the end user. For example, in a leave application form the leave start date should be always before the leave end date. When a user configures a form in App Studio, they define the validation that will apply to the form which will include defining a set of conditions and an error message. When the set of conditions returns true, the defined error message is displayed for the corresponding field after the user submits the form (assignment). To learn more about creating form validations, see [https://community.pega.com/sites/default/files/help_v84/express/procomhelpmain.htm#case-management/form-builder/cm-adding-validation-to-step-tsk.htmLearn Validating field input]. When a user creates a validation in the view configuration window for an assignment, internally it creates a validate rule. The auto-generated validate rule is referred from the flow action of the assignment. For advanced validation configurations which are not supported in App Studio, the user can open the corresponding validate rule and update the rule form. To learn more about validate rules, see [https://community.pega.com/sites/default/files/help_v84/procomhelpmain.htm#/pxadminstudio/rule-/rule-edit-/rule-edit-validate/main.htm About Edit Validate rules]. ===== Remember: Keep validations out of the UI Layer ===== This form validation is applicable for the case through any channel including web, mobile or API and therefore is the best way to define validation for forms because it provides the most flexibility. If instead you use the option to mark a field as mandatory in the view configuration window in App Studio, the validation is restricted to the UI layer. When the case is processed through an API or other channels which don't use this UI, the mandatory option won’t be applicable and will cause problems. == Stage validation == Moving from one stage to the next relies on capturing data or receiving required approvals or when a specific event happens. It is important to have validations defined which would let the user know when some required conditions are not met before transitioning to a stage. Users achieve stage validation with simple configuration in the '''Data model''' tab of a case type. In App Studio, the '''Validations''' tab can be found on the '''Data model''' tab of a case type. In the '''Validations''' tab, a user can view the fields and stages in a matrix format. Based on the stage and field for which the user would need to define the condition, the user can click on the corresponding cell. At run time whenever the defined condition would be true, the configured error message would be shown on top and beside the selected field. The condition would be evaluated before transitioning to the given stage and error would be shown when the condition returns true. To learn more about about stage validation, see [https://community.pega.com/knowledgebase/articles/case-management/84/requiring-property-values-stage-entry Requiring property values for stage entry]. Internally this model-driven stage validation creates a ''pyOnStageEntry'' validate rule for the case type. For advanced stage validation configurations which are not supported in App Studio, a user can open the ''pyOnStageEntry'' validate rule and update the rule accordingly. For attachments, a user can define the validation condition to check if there are any files attached for a given attachment type field. If the user doesn’t use an attachment field and got only attachment categories, they can use the '''Attachments required for stage entry''' in the case designer in Dev Studio to make sure attachments from the required categories are attached before transitioning to the next stage. For more information, see [https://community.pega.com/knowledgebase/articles/case-management/84/requiring-attachments-stage-entry Requiring attachments for stage entry]. == Validation on case creation == If you want to make sure that some of the fields are completed or want to mandate some relationships between some of the fields for a case being created, then case creation validation needs to be defined. To define case creation validation, a user can go to the '''Validation''' tab of the case settings and click on '''configure''' for '''When case is created'''. This would guide the user to create an ''OnAdd'' validate rule in the case type class. The user can configure the validate rule to define the conditions and error messages. This ''OnAdd'' validate rule will be invoked automatically by case run time before creating a case. Like other validation scenarios when the condition is met, an error is displayed and the case is not created. == Validation on case save == If you have a condition which you would like to be validated whenever the case is saved, then validation on case save is the suggested way. To define validation on case save, user can go to the '''Validation''' tab of the case settings and click on '''configure''' for '''When case is saved'''. On click of that it would guide the user to create a ''Validate'' validate rule in the case type class. The user can configure the validate rule to define the conditions and error messages as per their business needs. This Validate rule will get invoked automatically by case run time before the case is saved. Please note the difference between this validation on case save and form validation. If there is a validation condition which should be checked in all the assignments across the case type, then it makes sense to define it as case validation, otherwise form (assignment) level validations should be configured. Both can co-exist as well where the common validation conditions can be defined in the case save validation and the form-specific validation can be defined at the form validation. == Related content == * [https://community.pega.com/knowledgebase/articles/case-management/84/requiring-property-values-stage-entry Requiring property values for stage entry] * [https://community.pega.com/knowledgebase/articles/case-management/84/validating-case-data Validating case data] * [https://community.pega.com/sites/default/files/help_v84/express/procomhelpmain.htm#rule-/rule-edit-/rule-edit-validate/related.htm More about Edit Validate rules] * [https://community.pega.com/knowledgebase/articles/application-development/84/about-constraints-rules About Constraints rules] * [https://community.pega.com/sites/default/files/help_v84/express/procomhelpmain.htm#case-management/form-builder/cm-adding-validation-to-step-tsk.htmLearn Validating field input] * [https://community.pega.com/sites/default/files/help_v84/procomhelpmain.htm#/pxadminstudio/rule-/rule-edit-/rule-edit-validate/main.htm About Edit Validate rules] * [https://community.pega.com/knowledgebase/articles/case-management/84/requiring-attachments-stage-entry Requiring attachments for stage entry]

Return to Apply validations to ensure data integrity.