Validations

The following section explains what Validations are, and how you can define them.

Why do I need Validations, and what are they?

Validations are used to ensure that any information which is entered into the application adheres to certain rules. Some of these rules are of a technical nature, but most rules will be defined by the individual clients, based on the requirements of their business processes. Validations are necessary to maintain a high data-quality within the system, which in turn will also increase the quality of the information which is extracted from the system.

The system will validate each field "as you go", upon modifying/exiting a field.
In addition, validations are run again when the record is saved, to capture any potential outstanding issues on pages or subform records which are/where not in view.

Should it detect that one, or several of the rules are not met, the Web Application will NOT save the record and instead display the corresponding error message(s), indicating what the user needs to change so that the validation passes and the record can be saved.

Examples for Business Validations are to validate that:

• The Incident Reported Date cannot be in the future.
• The Action Due Date cannot be before the Action Date Raised.
• The Action Due Date cannot be more than 28 days in the future,
  but only WHEN the Action Priority is Urgent.
• The Closeout Comment has a value,
  but only WHEN Close this Incident? has been set to Yes AND the Closeout Date has a value.
• The Employee Number or a person's Email Address must be unique.

The system also performs System Validations, to ensure that the data entered can be saved to the database. These validations are applied automatically, there is no need for configuration of any of the following:

• Number fields cannot accept characters.
• Date and time fields have to be entered in the correct format.
• Text fields cannot contain more characters than the underlying database field.

What is required to define Validations?

Before defining the Validations it will be necessary to identify what the actual business requirements are, which can be different from business to business.

Note that you can only define Validations for fields which are actually shown on a Form, so a user has the opportunity to actually correct what may be wrong.

While some validations will be straight forward, for example that a Date reported cannot be in the future, others will be more complex.
This is because sometimes validations will only be necessary WHEN certain other conditions are met - and the main effort will be to identify these conditions.

Once I have defined a Validation, when will it be available to the End Users?

Every change made to a Form, being:

• Changes to the Form itself (adding/removing fields, changing labels etc.)
• Making changes to Actions, Validations and Default Values

will require a Publish, and a restart of the Tomcat Web Server.