Validation is the process of ensuring that the data being stored contains values that are acceptable for the circumstances. It cannot ensure the values are correct, but simply that they are within acceptable bounds.
Validation can be carried out in different ways:
Pre-submission validation
This type of validation is carried out on a Data Entry Form when the Submit button is clicked. The validation is executed, and if any of the fields fail validation, submission is prevented, the user is given an indication of the affected fields, and allowed to correct them before reattempting submission.
To configure pre-submission validation, on the Data Entry Form’s Record Edit surface, for each field, configure the Validation tab.
Then, on the Submit button, check the box to require validation.
User Feedback
You will usually want to provide feedback to the user as to why their submission failed.
The Data Entry Form provides a Table - Error text surface that should be embedded on the Data Entry Form in the usual way.
After embedding the Error Surface, click the 'Edit text surface' button, and embed the 'Table - Error list' and any additional standing text.
Then if Validation fails a dynamic list of failed validations will be displayed for the user to correct.
Tip:
You can style the validation report by enclosing it within a <DIV>, for example:
<div style="color:#ff0000;font-size:18px;">
<div class="ncEmbed" data="Embed.69.0"><img class="IconSprite EmbedIconSprite" src="https://www.example.com/v/images/blank.gif" style="background-position: 0px -1521px;" />Table - Error list</div>
</div>
Post-submission validation
This type of validation is performed after the form has been submitted, by actions configured within the Record Change event. The method is to test the values of the fields involved, and if they are acceptable, set a status field to indicate the process flow has progressed to the next stage. If on the other had the validation has failed, then the status field is given a different value to indicate this.
Since the validation is happening asynchronously, the user may not be around to make an immediate correction, so the need for correction must be indicated by showing the record in a report page. This would typically be designed to list any number of records requiring attention, as the user may not return for a while. The post validation could also email the user to draw their attention to the issue.
Post submission validation is more flexible than pre-submission validation, as it is able to consider situations where the submitted fields may be acceptable individually, but not be compatible when considered together somehow.
In the screenshot below a set of actions and conditions are used to handle a post submission validation situation where the system is looking for inappropriate language in a message, and then taking differing actions depending on settings elsewhere in the system:
Postponing validation
There are situations where it is appropriate to ignore the values of submitted fields until a later time. This is useful if you allow a user to save their submission when it is part completed as a ‘draft’, allowing them to return later to finish it before finally submitting.
To configure a data Entry Form to allow validation to be postponed, on the Submit button’s properties, uncheck the option to perform validation.
Note: You can place more than one Submit button on a form, so one can be set to ‘Save’, and one to ‘Save as Draft’, with only the ‘Save’ one set to require validation.
Then to allow the system to know which button was pressed, when executing the Record Change event, the buttons should be configured to set an identifier text value in a specified text field.
