Data Validation

Overview

A good mindset when creating applications is to validate your end-user's input. Data validation is how you ensure that data entered into your system is correct. End-users could enter incorrect information because of a keyboard mishap or general misunderstanding. If your application accepts any input in any field, the result may be unusable data.

The key with validation is that it happens at the time of entry, lessening errors. When an error occurs, you can offer your end-users guidance via error messages. End-users can then immediately correct errors.

Validating data ensures that the data in the system is the data you expect. Validation increases data integrity. While building your application, the Module Builder offers several ways to validate data. Let's take a look at these validation methods.

Data Type Validation

The first part of your validation journey starts with the component you drag and drop to your canvas. It's best practice to use a component that best matches the data you're gathering. For instance, Number, Date, and Email confirm that end-users input the correct data type. When you select a component that specifies a data type, you do not have to build separate validation.

For example, for email addresses, you'll want to use an Email component. This component verifies whether an end-user has entered all 4 parts of a valid email address. The parts include: username, @ symbol, domain name, and top-level domain name (.com, .org). A message below the field lets your end-user know that the email address is not complete. While the component verifies the format is correct, it does not check if the email address is real.

Component Validation Panel

Data validation isn't your only validation option. Input components also include input-related validation settings. For example, requiring input or setting a minimum or maximum input length. Let’s take a closer look at the settings available on the Validation panel.

Required

Setting a component to Required is the simplest form of validation. When set to ON, your end-user must enter an input before they can navigate ahead or save their submission. You can use this type of validation on fields which must have data entered into them. Setting a field to Required also ensures your end-user completes any important fields. Set the Required toggle to OFF when data entry is optional.

Minimum Length and Maximum Length

Length checks make sure that the character string entered is not too short or too long. For example, consider a driver’s license that needs to be 8 characters long. Using Minimum and Maximum length validation ensures your end-user enters exactly 8 characters.

The Text Field and Text Area components have two more Maximum Length settings. Show Maximum Length Countdown lets your end-user see the number of characters remaining. And Allow Typing Beyond Maximum Length shows a message when the text reaches the maximum. End-users can continue to enter text beyond this point, despite the notification.

Error Messages

When end-users enter invalid information, you want to help them understand their mistake. This is where error messages come in. Error messages are a way to communicate to your end-user what their input should look like. An error message should provide details on the problem and offer a solution. Each error message has default text that you can change. If you do adjust your error message, keep it brief and clear. Your goal is to help your end-user.

Different components have different error messages available. Types of error messages include:

Error Message

Description

Required Error Message

This message lets your end-user know that they must make an entry in the field before continuing.

Minimum Length Error

This message lets your end-user know that they've not entered enough characters in the field.

Maximum Length Error

This message lets end-users know that they have entered too many characters in the field.

Custom Error Message

Only available for the Checkbox component. You can set specific parameters apart from requiring the field. For example, you may stop your end-user from selecting more than 2 items from the list. If they select a third item, this custom error message shows.

Email Error Message

This message lets your end-user know they've entered an invalid email address.

File Size Error Message

This message lets end-users know that their uploaded file exceeds the maximum size.

Require Unique Submission Data

There may be times when you want to ensure that an answer is only entered once. Meaning the data is unique. The Require Unique Submission Data setting is available for the following components:

  • Radio Buttons

  • Multi-Select Dropdown

When set to ON, the end-user cannot select an option that already exists in a submission.

Don't Allow Unique Values

The Multi-Select Dropdown lets your end-user select an item from the list or enter their own text. To prevent your end-user from adding text, you'll set the Don't Allow Unique Values toggle to ON.

When set to OFF, your end-user can enter their own value into the drop-down field. The field accepts the input even if it doesn’t match any of the existing values in the drop-down. When set to ON, your end-user can only select an existing value from the drop-down.

Valid Number

Next, let's look at the Number component's unique validation options. These include the Minimum Number and Maximum Number settings. These 2 settings are great for scenarios where you want to set a range of acceptable values.

Say you have an application that's a portal where contractors track the hours they worked in a week. Each of your contractors has an approved number of weekly hours of 30 to 35. This is a perfect opportunity to define a range of acceptable values. You could set a Minimum Number of 30 and a Maximum Number 35. You could even set up Minimum or Maximum Number Error Messages. So, if your end-user types in 29 or 36, your app shows a message asking your end-user to reach out to their team lead.

Date Restrictions

When using a Date Input component, you can limit the range of dates end-users can enter. For example, when capturing a birth date, you want to avoid a 1-year-old or a 251-year-old entry. In that case, you’d Restrict To Between Dates and select dates that represent the average age range. Perhaps no younger than 18 and no older than 120 years old.

The following validation settings are available for the Date Input component:

Setting

Description

Restrict To

Limits your Date Input field based on the date restriction selected. Available date restrictions include:

  • None: Displays all dates without restrictions. The end-user can select any date in the future or the past.
  • Future Only: Only displays future dates.
  • Past: Only displays dates in the past.
  • Before a Date: Only displays dates earlier than your chosen date.
  • After a Date: Only displays dates after your chosen date.
  • Between Dates: Only displays dates within your chosen date range.

From

Specify the from date.

Using the drop-down menu, you can apply more restrictions to the start of your date range:

  • Absolute Date: Choose the oldest date the end-user is allowed to enter.
  • Relative Date: Choose the earliest relative date the end-user is allowed to enter. Accepts negative values.

  • Now: Sets the current date as your starting date.

  • +∞ (Past Only): Accepts all dates from the past. Same functionality as the Past Only setting.

Until

The Until field shows on selection of the Between Dates date restriction.

Using the drop-down menu, you can apply more restrictions (Absolute Date, Relative Date, Now, Future Only) to the start of your date range.

  • Absolute Date: Choose the earliest date the end-user is allowed to enter.
  • Relative Date: Choose the latest relative date the end-user is allowed to enter. Accepts negative values.

  • Now: Sets the current date as your starting date.

  • +∞ (Future Only): Accepts all dates in the future. Same functionality as the Future Only setting.

File Upload Validation

The File component adds an easy-to-use file uploader capability to your app. This can be useful for situations like uploading images of a driver's license, or a PDF of a resume. The File component lets you create a few validation rules. This includes the maximum file size and the type of files available for upload. Say your current systems only support Word documents, not PDFs. Setting a file type validation can save you headaches down the road.

The following validation settings are available for the File component:

Setting

Description

Set Maximum Size

Validation that limits the size of each file an end-user can upload. It might take longer to upload larger files depending on the browser and network connection.

This value must be equal to or less than your use case's file size limit. These thresholds are 18 MB, 100 MB, and 500 MB. To learn more about file size limitations, see our Working With Files in Unqork article.

Set File Formats to Accept

Sets the file types accepted by this component. To allow the upload of any file type, simply set the field value to *. To limit file types, list the approved file types adding a comma between each value (for example, .jpg,.png,.gif).

Input Mask

Using an Input Mask is a way to ensure your end-user’s inputs follow a specific format. For example, only using numbers when entering a social security number. You can even use Input Masks to set alphanumeric patterns. For example, the input mask for a Canadian postal code would be X9X 9X9. When setting an Input Mask, X represents any letter and 9 represents any number.

These components include Input Mask settings in their Display panel:

  • Text Field

  • Text Area

  • Email

  • Phone Number: The Input Mask defaults to (999) 999-9999.

By default, the Text Field and Text Area components have the Use Input Mask toggle set to OFF. If you want to use an Input Mask in these components, first switch the Use Input Mask toggle to ON.

Decisions Component Validation

The Decisions component is a logic-type component, often used in if/then scenarios. The Decisions component has many output types, including Required and Required and Visible. These 2 output types let you build conditional validation rules into your app. For example, setting one field to Required based on what your end-user enters in another field.

Let's look at an example of when you could use the Required and Visible output type. Say you're building an app where end-users can apply for a variety of financial services. Only one of these services, opening a new account, has an age requirement. So, you could set a Decision to only show and require an answer to the question "Are you over 18?" if your end-user applies for a new account.

Another option is to always display the “Are you over 18?” question. Instead of conditionally showing the question, you'll conditionally require it. So, you'll only need to use the Required output type. This way, your end-user only needs to enter their age when they select New Account.