Data validation in Dev Studio

In App Studio, you can configure validation conditions that perform a true/false comparison to the value of one field against either a constant value or the value of another field. More complex validation scenarios might require additional capabilities that are provided by validate rules in Dev Studio.

Consider the following scenarios, each of which requires behavior that you can configure only in Dev Studio:

• When a Canadian customer submits their address, the postal code entry must conform to the standard format for Canadian postal codes.
• When an investor opens an investment account, they complete a questionnaire to determine their experience level. Only individuals with extensive investing experience can add margin trading to their account.
• When a person enrolls in a healthcare plan, the applicant must upload a consent form to allow disclosure of medical information to third parties.

Validate rules

Validate rules ensure that the data that your users provide meets the conditions that a case requires in order to go forward. By assigning validation rules to flow actions, you can prevent users from entering information that your application cannot process and reduce the number of processing errors.

In Dev Studio, you can extend validate rules that are created automatically in App Studio. You can also create new validate rules in the Process category.

Edit Validate rules

Edit validate rules are typically applied to properties, and consist of Java code that compares the value of a property to a defined pattern. For example, an edit validate rule can check whether a property value consists of seven numbers, with a space separating the third and fourth numbers. If the pattern match succeeds, the input is considered valid. Otherwise, the system flags the input with an error.

Edit validate rules are used for client-side validation, which means that the value users enter is validated immediately without referencing the server. Validation occurs when users make a change to the entered value. To apply an edit validate rule to a property, reference the edit evaluate rule on the Advanced tab of the property rule form, in the Use validate field.

Business logic might dictate that user input meets certain standards. For example, to capture contact information for a user, an organization needs to ensure that the information is valid. Before an application can confirm that a postal code, email address, or telephone number are accurate for a user, the application must confirm that the user entry conforms to a specific format that might vary based on location.

The following example demonstrates applying an edit validate rule from a validate rule, to ensure that a user enters a postal code that conforms to the United States ZIP Code format, which requires five numerical digits.

Check your knowledge with the following interaction.

Business logic might require that an application validates data differently based on certain conditions, such as user input, case status or stage, or a user action. This can be accomplished with a validate rule.

Consider a case type for opening a new investment account. A financial services firm might offer the option to trade securities on margin by lending funds to the customer to purchase stocks or other allowed investments. This lending, known as a margin loan, requires the customer to maintain a certain ratio of loan balance to account value, such as 30%. The firm wants to ensure that customers use margin wisely and limit the need for a margin call, a request to provide additional funds or selling an investment automatically to restore the ratio between loan balance and account value. Investors with extensive investing experience present a low risk for a margin call, while investors with limited experience present a much higher risk. In addition, accounts that limit contributions on a yearly basis, such as retirement accounts, prohibit margin trading altogether. To satisfy this requirement, you can conditionalize the validation logic based on the account type and experience level.

To qualify validation logic, use the Input tab of the validate rule to identify the type of qualification to apply by selecting one of the options.

• Input property – Qualify validation based on data that is provided by the user. In the new investment account example, both the experience level and account type fields are used to specialize the validation logic.
• Proposed work status – Qualify validation based on the status that the application applies to the case. For example, a request for a credit card is based in part on the customer credit score. For the Pending-Qualification status, the credit score can be as low as 600, while changing the status to Approved requires a minimum credit score of 725.
• Flow action – Qualify validation based on the action that is performed by a user. For example, a form containing employee information requires the starting date of employment. If the user wants to run onboarding for a new employee, the start date must be in the future. If the user wants to perform an annual review of an employee, the start date must be in the past.
• Stages – Qualify validation based on the current stage of the case. For example, to apply for a mortgage or home equity loan, the customer must indicate their annual income. During the Submission stage, the application requires the user to provide an estimated income. During the Approval stage, the estimate must be replaced with a confirmed, concrete value.

The following example demonstrates input-qualified validation. The value that is selected in the Experience level list determines the validation condition that is applied when you submit the form. If the user selects Experienced or Professional, margin trading is allowed and the check box to enable margin trading is not validated. If the user selects Limited, an error is displayed if the user selects the check box to enable margin trading.

In center of the following image, slide the vertical line to view the configuration of the input-qualified validation and the result.

App Studio supports true/false comparisons between two property values or a property value and a constant. In cases where you cannot configure this type of comparison, you can access a library of validation functions on the validate rule form in Dev Studio. For example, you can use a function to check whether a date falls within the past four or eight weeks or to check whether a user has uploaded a specific type of attachment to the case. Each function presents a customized set of fields for configuring validation behavior.

The following example demonstrates the use of a function to configure validation. The validate rule uses the function A [attachment category] is [attached/not attached] to the current case to ensure that the user attaches a document that demonstrates proof of identity as part of the process for onboarding a new employee.

In the center of the following image, slide the vertical line to view the configuration of the attachment validation and the result.