Web Validation Syntax

Follow
.+

This will make the field required, but allow any characters input into the field to pass validation.

[Customizing the Web Interface^
\d\d\.\d\d\.\d\d\d\d$]

This format is for an MM/DD/YYYY date.

^\d{9}$

This is for a nine-digit number.

^(\d{5,5})-(\d{4,4})$

This is for a zip code that will take 5 digits or 5-4 digits.

\w+\@\w+

This format is for an E-mail address in the format illiad@atlas-sys.com.

  • Carats ( ^ ) at the beginning of strings mean that it must start with those values.
  • Dollar signs ( $ ) at the end of strings mean it must end with those values.
  • A plus sign ( + ) means that the previous parameters are required.
  • An asterisk ( * ) means that the previous parameters are optional.
  • Certain characters like periods, pipes, question marks, brackets etc, are special characters within regular expressions. If you want to match on the literal value of that character, you must proceed it with a backslash ( \ ). For example, the value of \. in any regular expression would then mean that a literal value of . would be required.

There may be cases where WebValidation entries do not support UTF8 characters. For example, if the WebValidation entry requires an n~, the validation will not pass.

Example - ID Numbers

One field validation that is commonly changed is the SSN field. This field stores a unique identifier number for the customer. Sometimes this is an actual social security number. Other times it is some other unique number, such as a student number, employee number, barcode number, etc. 

A standard SSN format, nine digits with no hyphens, would be expressed as:

^\d{9}$

Or a 14 digit number would be expressed as:

^\d{14}$ 

Should the need arise to combine the two formats, for example if you wanted to accept EITHER format, but not anything else, you can combine them with the alternative metacharacter ( the | ) as follows:

^\d{9}$|^\d{14}$

Thus the following expression:

^\d{9}$|^\d{14}$|^\d{21}$

would accept a 9, 14, or 21 character string of numbers.

Example - Email Addresses

If you wanted to restrict what kind of email address a customer could enter, you could do so with a variety of formats. In the values below the section reading [_A-Za-z0-9-] translates to any underscore, dash, letter or number.

^[_A-Za-z0-9-]+(\.[_A-Za-z0-9-]+)*@[A-Za-z0-9-]+(\.[A-Za-z0-9-]+)*$

The above example would only let an address with letters, numbers, underscores or dashes followed by an @ symbol followed by letters, numbers, or dashes validate and be entered into the system. This would prevent users from typing "none" in the email address field, and would force them to enter somebody@someplace.somewhere in that field.

^[_A-Za-z0-9-]+(\.[_A-Za-z0-9-]+)*@atlas-sys\.com$

The previous example would force any address to have to end in @atlas-sys.com.

^[_A-Za-z0-9-]+(\.[_A-Za-z0-9-]+)*@([A-Za-z0-9-]+\.)*atlas-sys\.com$

The previous example would force any address to end in @atlas-sys.com or @mail.atlas-sys.com or @anythingelse.atlas-sys.com etc.

Questions?

If this article didn’t resolve your issue, please take a moment and answer a few questions to help improve our documentation:

Feedback