Validation tips in Jitterbit App Builder

Validation Rules in App Builder are a way to protect your data from unwanted or improper data manipulation. Validation Rules are configured in the Business SQL area of the Business Logic Layer, and once they are configured can be used in the application by adding them as Controls to Panels on Pages.

This article provides some best practices and recommendations when working with Validations in App Builder. Validations are used to protect data integrity. They can be run against data getting manually entered in and prevent a User from adding records that violate Business Logic (for example, duplicate records). Validation Rules can also be used in the Business Logic Layer. If a CRUD Rule is set as Business Layer, Validations will run as well when that CRUD Rule is executed.

Validation messages presented to end Users are configurable and can leverage dynamic substitution for improved User experience.

Validation rule tutorial

Best practices and recommendations

99% of the time you should use Implicit binding. Explicit binding is used for XP Validations (such as to a REST API). Explicit binding may not break your Validation.
Your Validation should target either the table or the panel data object. If you want to register at the table level so it executes anytime a record is saved through any data object, then you would target the table and register at the table level. If you want to register to the data object, then target the data object.
The real trick becomes knowing how the Temporary/New ("In-Memory") record gets referenced in the Validation rule to check against existing rows. {{nm.ab}} will replace any business object with the new record in the following scenarios:
1. Replaces the first target table added to the Validation rule. Second one is untouched. This is actually in the order they were added.
2. Replaces all data object's that target the same target table that the panel/event targets.
  - See Replacement Scenarios section below.
Important

This becomes very important when you want to validate a record against existing records. If you want to do this, then you need to add the target table twice or consider adding a business object that does not target the same table targeted by the event.
If building a Validation rule that uses the "In-Memory" approach, the business object from which the validation rule is registered must contain all columns referenced in the Validation rule to successfully "replace" all the column values.
- See the Duplicate Email "In-Memory" example below for a sample configuration.
Validations triggered on business rules run in actions aren't able to perform confirmations. They will get rounded up to errors. There isn't a way to have half run your top level event, confirm something, then keep running it.
{{nm.ab}} supports dynamic substitution in the messages for Validations. All you need to do is supply the value you want substituted in the data object of the panel the Validation fires on, and then {{Value}} in the message field of the Validation.

Replacement Scenarios:

Customer, Customer (Source A), Customer (Source B): all gets substituted
Customer, Customer: First customer table gets substituted
Customer (Source A), Customer (Source B): All get substituted
Customer, Customer (Source A), Customer (I'm not targeting Customer) : Customer and Customer (Source A) are substituted

Duplicate Email "In-Memory" Validation Rule Example:

This example illustrates the "In-Memory" validation approach, where the value in which the user is typing out is checked against the values that are currently saved on the rows in the table. All columns in the Validation rule must exist in the Business Object in order for App Builder to successfully place the "In-Memory" values into the rule's columns for the logic to work.

Validation Registration example for a Duplicate Email Validation Rule:
Validation rule example configuration:
Where clause for Validation rule configuration:
Join logic for Validation rule configuration: