Using FieldValidation.aspx

TSL Ping Tree > Page Usage

Using FieldValidation.aspx

Field Validations are used to optionally constrain the values of Fields beyond the full limits of their data types.  For example, you can use a Field Validation to constrain an Integer to allow only values of -1, 0, and 1 as valid values instead of the full range allowed for an Integer (i.e. –2,147,483,648 to 2,147,483,647).  You could also constrain a String so that it has to be a valid US phone number, i.e. it contains 10 digits not counting punctuation and the area code and exchange valid per the current North American Numbering Plan NPA NXX database.  You could then attach this phone number Field Validation to String-based Fields that you have defined for “Home Phone” and “Work Phone”.

A Field Validation is similar to a Filter in that it has one or more rules where All Must Pass or Any Must Pass in order for the overall Field Validation to pass.  Where a Filter can be Global or else Attachable to Promotions, Ping Trees, or Lead Points, e.g., Field Validations are defined to work for a specific data type so that they can be attached to one or more Fields of that same data type.

Field Validations are executed at the start of each form submission as each Field on the Form is processed, after casting the value from String to the data type of the Field, in the order in which the Field is defined on the Form.  Each Field Validation failure will produce one or more Field Errors for the Field to which it is attached.


Configuration Item Description
Name A unique field validation name up to 255 characters.
Data Type A supported data type which can be CheckBox, DateTime, Decimal, Integer, or String.  Fields of the same data type are where this Field Validation may be attached.  Once a validation rule entry has been added the data type may not be changed.
Pass If When you have multiple field validation entries, this determines whether they all have to pass for the validation to pass (AND) or if any rule passing causes the validation to pass (OR).  If you only have one entry, then that single rule must pass for the validation to pass regardless of the "Pass If" setting.
Notes Anything goes here.
Enabled You can disable a Field Validation without removing it from all of the places where you used it.  Only enabled Field Validations execute.
Update Comment You can provide a comment here to be included in the audit trail entry when updating the Field Validation.
Entries Here is where you define one or more rules that make up the definition of this validation. See below for a detailed explanation of these entries.

Field Validation Entries

You can define one or more rules that make up a field validation. The settings that define one rule are:

Configuration Item Description
Note A description of up to 255 characters that describes the individual entry.
Filter Mode A rule may be of type Require or Block.  Require means that the current lead must match the rule while Block means that the current lead must NOT match the rule.
Filter Style A rule can be a simple wizard type rule with an upper bound, a lower bound, and/or a modifier chain -styled built-in Check validation or it can be an extremely powerful lefthand/righthand expression.

Wizard Style Validations

You can use a wizard style entry when all you want to do is constrain minimum and/or maximum values (or minimum and/or maximum lengths for strings) and/or run a modifier chain -styled built-in Check validation such as CheckABA or CheckMX.

A minimum value, maximum value, or modifier chain constraint must be defined for each entry.  When using a modifier chain -styled built-in Check validation the data type of the Field Validation must match the IN data type of the first modifier.  Each subsequent modifier's IN data type must match the previous modifier's OUT data type; this keeps the modifier chain valid and modifying the starting value to produce some end result.  In this case the end result has to be of type CheckBox; several CheckXYZ modifiers exist that produce a CheckBox value as their OUT data type.  The most powerful such modifier is CheckRegEx for evaluating Regular Expressions.  Regular Expressions are not very easy to express but they are powerful.  A simple example of a Regular Expression is CheckRegEx("^(na|n/a|no answer|not applicable)$") which matches the whole strings "na", "n/a", "no answer" and "not applicable".  For more help on Regular Expressions see the online help article for Regular Expressions.

Following are the constraints that can be configured based on the selected data type:

Data Type Description
CheckBox You can either specify that the checkbox should be checked or unchecked.
DateTime You can either specify a relative date range or an absolute date range.

A relative date range allows you to specify a minimum and maximum date (in any order) that is based on the current time (Now) or on a selected DateTime Field or Global Constant.

An absolute date range allows you specify a specific start and end date that a value must fall between. One of the values for an absolute date range can be left blank to indicate Now.

Note that the system uses Now in the US Eastern Standard Time zone which makes comparisons in short time frames problematic for other time zones.  Tip: For longer times periods add an extra day.
Decimal You can specify a minimum and maximum value.  If a minimum or maximum value is left blank then there is no constraint for that item.  For example you can set the minimum to 0.00 and leave the maximum value blank to indicate that the value must be greater or equal to 0.
Integer You can specify a minimum and maximum value.  If a minimum or maximum value is left blank then there is no constraint for that item.  For example you can set the minimum to 0 and leave the maximum value blank to indicate that the value must be greater or equal to 0.
String You can specify a minimum and maximum length.  If a minimum or maximum length is left blank then there is no constraint for that item.  For example you can set the minimum to 6 and leave the maximum value blank to indicate that the value must be have contain at least 6 characters.


Lefthand/Righthand Expression Style Validations

You can use a lefthand/righthand (LH/RH) expression style entry when you want to do more sophisticated filtering such as checking whether a String value is contained in a String List or using more than one field to perform a validation. A LH/RH expression can be thought of as a comparison in the format:

     LEFT_HAND_EXPRESSON   COMPARISON_OPERATOR   RIGHT_HAND_EXPRESSION

Examples:
  • ${sp.'Affiliate ID'}|${sp.'Affiliate/Promotion Authentication Key'}   Is In String List   Affiliate List
  • ${f.'Home Phone'}   Does Not Equal   ${f.'Work Phone'}

Important: When one side of a LH/RH expression is a constant value or a String and the other is a DateTime, Decimal, or Integer then the String will be cast into the correct data type using the rules for the "en-US" (English - US) culture.


The settings for a LH/RH expression entry are:

Configuration Item Description
Left Side This is the left hand value of the expression.
Comparison This is the comparison operator of the expression.
Right Side This is the right hand value of the expression or in the case of the operators "Is In String List" and "Is Not In String List" this is the name of the String List
Error Message This is error message that will be generated if the comparison of the expression is True.  It may contain ${} style tokens. This field is required.