Field validation is critical for delivering the best user experience when completing a form. The purpose of this document is to highlight some of the best practices around form validation and describe different options that are possible in the Pega Platform.

They are 2 fundamental principles around validation

• It should not be restrictive and the user should be able to enter the correct information without having to follow a pre-described templates. Several studies shows that users enter phone number differently (use space or dash separators for example) or credit card number - this study is a good introduction on the challenges related to entering a credit card. 
• It should be immediate - The user should not have to submit the form to identify incomplete entries or validation errors. As such it is critical that all validations are done first on the client side, during the onchange event or on every key entered by the user.

Here are 3 different options to implement field validation in the Pega platform.

1/ Using edit validate rules

Edit validate rules have been in the platform for several releases and are implement as a java code. The main usage is to validate and transform a value during server processing. But one of the main feature of the edit validate rule is that it is possible to create a similar functionality on the client side. In the Pega platform, a couple of edit validate rules like SSN, ZipCode or USPhone are provided with both the java code as well as the javascript code - the JS function will automatically run on change without the need to configure any special action set on the field - for more details refer to this community article and the file pega_validators.js

Let's look at the SSN example using the edit validate rule

We can see several ways to improve this validation:

a/ user should only be able to enter numbers and dash or space. Other characters should be blocked and not allowed instead of waiting for the validation on change

b/ user should know when all 9 digits have been entered and should not be allowed to enter more digits

c/ on a mobile device, the keyboard should be the number keyboard instead of the text keyboard.

the last issue is difficult to address using this edit validate rule because the property holding the SSN will be stored as a string and will be formatted on the server using number and dashes - As such it is not possible to rely on the HTML5 input[type='number'] since the SSN is not really purely a number but more a string.

2/ Using input masking

the method called input masking consist at automatically formatting the value on every user key. Combining input masking with rule edit validate will help address the issues a/ and b/ listed above. There are a lot of different libraries available to perform input masking - One of the oldest one is called Jquery input mask see https://igorescobar.github.io/jQuery-Mask-Plugin/. input masking can handle complex rules where you can enforce number, optional characters, delimiters. It is also possible to render a mask in the input field when focusing on the empty field or not.

Input masking guides the user during typing and significantly helps reduce the number of mistakes or invalid entries. Let see the same SSN using both input masking and rule edit validate

The only need for the rule edit validate after using input masking is if the user enters less characters than expected. In this case, the error can provide the expected format and help the user. With input masking, the need to show the expected format in the helper text is no longer needed and it helps makes the form more readable (compared with the first example)

Note that input masking is challenging for entering a phone number - Most of the people have different ways to enter a phone number and this could be a challenging task to have the correct input mask rules for each type of phone number. As such if you ask the user for an international phone number, it is recommended to let the user enter the phone number as freely as possible - you can read this article for more details on this topic.

3/ Using multiple fields

This method is usually the one that is not recommended for all scenarios for multiple reasons:

• it bring accessibility issues since each input is now focused by the screen reader
• it requires the user to navigate to the next input field by tabbing out
• it does not support copy / paste easily

For more details, I recommend this article.

These 3 issues can be addressed by the control. The multiple field will work well if all entries in the property are expected to be of the same type and will not change or vary greatly between users. the SSN for example is a good candidate for using a multiple input field. Phone number or credit card is not (number of digits for the credit card varies greatly between different credit card companies)

In the case of the SSN, the multiple field will address the issue c/ listed above where on a mobile phone, the user will have an input keyboard to enter the digits 

Let's look at a generic implementation of such component that correctly handle focus change and paste and only allow digits to be entered

While it is possible to achieve similar behavior in the Pega platform using 3 input fields, it will require a lot of extra work to get it to work and will be difficult to maintain. You will need 3 temporary properties to hold each input field, you will need to concatenate the 3 values and store it in the final property. Finally you will not be able to render a single error validation message as shown above - each input field will render an error message with wrapping issues.

For more details on these 3 options, you can check the UI gallery example in 8.5.2.