Validation Set

Overview

A Validation Set Logic Block aggregates multiple validations that are evaluated together. Instead of defining many individual Validation blocks, a Validation Set groups related validations into a single, cohesive unit.

Validation Sets are ideal when:

• Multiple validations apply to the same entity or scenario
• Related validations should be managed together
• You need comprehensive validation feedback
• You want control over evaluation behavior (all validations vs. stop on first failure)

How Validation Sets Work

A Validation Set contains multiple validations. When invoked, you can configure the evaluation behavior:

Evaluation Modes

Mode	Behavior	Use Case
Evaluate All	All validations are evaluated regardless of failures	Show users all issues at once for comprehensive feedback
Stop on First Failure	Evaluation stops when the first validation fails	Fail fast for performance or when subsequent validations depend on earlier ones

Evaluate All Mode

When configured to evaluate all validations:

1. All validations are evaluated (even if some fail)
2. Results are aggregated into an overall pass/fail
3. Individual results are available for detailed feedback
4. Error messages are collected from all failing validations

This mode is ideal for user-facing validation where you want to show all problems at once, rather than making users fix issues one at a time.

Stop on First Failure Mode

When configured to stop on first failure:

1. Validations are evaluated in sequence
2. Evaluation stops when a validation fails
3. Only the first failure is reported
4. Remaining validations are not evaluated

This mode is useful when:

• Later validations depend on earlier ones passing
• You want to optimize performance by avoiding unnecessary checks
• The validation order represents a logical sequence of prerequisites

Structure

A Validation Set consists of:

Component	Description
Name	Unique identifier for the validation set
Description	What the validation set checks
Inputs	Shared data available to all validations
Validations	The member validation rules within the set
Evaluation Mode	Evaluate All or Stop on First Failure
Outputs	Overall boolean result plus the name(s) of any failed validation(s)

Validations

Each member validation within the set has:

• Validation Name: Identifier for the specific validation. This name is what the set reports when a rule fails.
• Condition: The boolean expression that must be true for validity

Validation Sets track validity by rule name. When a rule fails, the set records that rule's name - there is no per-rule severity level or stored message at the block level (a friendly message can be resolved where the result is consumed, e.g., in a Recipe or Flow).

Try It Live

Toggle the evaluation mode to see the key difference: Evaluate All shows every failure at once, Stop on First Failure halts at the first error. Edit the pre-filled inputs to fix or break different rules.

⊏⊐ValidateCustomerRegistrationValidation Set● AUTO

Evaluation Mode

InputsFirst NameLast NameEmailPhoneAgeAccept Terms & Conditions

Validation Results

✓FirstNameRequired

✗LastNameRequiredLast name is required

✓EmailRequired

✗EmailFormatEnter a valid email address

⚠PhoneFormatPhone must be at least 10 digits

✗AgeRequirementMust be 18 or older to register

✗TermsAcceptedMust accept the terms and conditions

✗ Invalid · 4 errors

Example: Customer Registration Validation Set

Name: ValidateCustomerRegistration

Evaluation Mode: Evaluate All (show user all issues at once)

Inputs:

• FirstName (String)
• LastName (String)
• Email (String)
• Phone (String)
• DateOfBirth (DateTime)
• AcceptedTerms (Boolean)

Validations (the Error Message column is illustrative - the set itself reports the failed rule names):

#	Validation Name	Condition	Error Message
1	FirstNameRequired	FirstName != null && FirstName != ""	"First name is required"
2	LastNameRequired	LastName != null && LastName != ""	"Last name is required"
3	EmailRequired	Email != null && Email != ""	"Email address is required"
4	EmailFormat	CONTAINS(Email, "@") && CONTAINS(Email, ".")	"Please enter a valid email address"
5	PhoneFormat	Phone == null || LEN(Phone) >= 10	"Phone number must be at least 10 digits"
6	AgeRequirement	DATEDIFF(DateOfBirth, TODAY()) / 365 >= 18	"You must be 18 or older to register"
7	TermsAccepted	AcceptedTerms == true	"You must accept the terms and conditions"

Outputs:

• result (Boolean): true only if every member validation passes
• validation (List): the names of the validations that failed (empty when result is true)

Evaluation Example:

For inputs: FirstName = "John", LastName = "", Email = "john@email", Phone = "555", DateOfBirth = 2010-01-01, AcceptedTerms = true

Validation	Result
FirstNameRequired	✅ Pass
LastNameRequired	❌ Fail
EmailRequired	✅ Pass
EmailFormat	❌ Fail
PhoneFormat	❌ Fail
AgeRequirement	❌ Fail
TermsAccepted	✅ Pass

Output (Evaluate All mode):

• result = false (4 validations failed)
• validation = ["LastNameRequired", "EmailFormat", "PhoneFormat", "AgeRequirement"]

Example: Invoice Validation Set

Name: ValidateInvoiceForPosting

Evaluation Mode: Stop on First Failure (validations have dependencies)

Inputs:

• InvoiceDate (DateTime)
• DueDate (DateTime)
• TotalAmount (Money)
• LineItemsTotal (Money)
• CustomerStatus (Option Set)
• HasAttachedPO (Boolean)
• ApproverName (String)

Validations:

#	Validation Name	Condition	Error Message
1	InvoiceDateValid	InvoiceDate != null && InvoiceDate <= TODAY()	"Invoice date cannot be in the future"
2	DueDateAfterInvoice	DueDate > InvoiceDate	"Due date must be after invoice date"
3	AmountPositive	TotalAmount > 0	"Invoice amount must be greater than zero"
4	LineItemsMatch	ABS(TotalAmount - LineItemsTotal) < 0.01	"Total does not match sum of line items"
5	CustomerActive	CustomerStatus == "Active"	"Cannot invoice inactive customer"
6	POAttached	TotalAmount < 1000 || HasAttachedPO == true	"Purchase order required for invoices over $1,000"
7	ApproverAssigned	TotalAmount < 5000 || ApproverName != null	"Approver required for invoices over $5,000"

In this example, "Stop on First Failure" is used because validation #2 (DueDateAfterInvoice) depends on validation #1 (InvoiceDateValid) passing - if InvoiceDate is null, comparing DueDate to it would be meaningless.

Best Practices

Group Related Validations

Keep validation sets focused on a single entity or process. Create separate sets for different scenarios:

• ValidateCustomerForCreation
• ValidateCustomerForDeactivation
• ValidateCustomerForCreditIncrease

Choose the Right Evaluation Mode

Scenario	Recommended Mode
User input validation	Evaluate All (show all issues)
API/integration validation	Stop on First Failure (fail fast)
Sequential dependencies	Stop on First Failure
Independent checks	Evaluate All

Name Validations Clearly

A Validation Set reports failures by rule name, so the names double as the failure output. Use descriptive, self-explanatory names (DueDateAfterInvoice, CustomerActive) rather than generic ones (Rule1, Check2) - they make the result easy to interpret and act on.

Order Validations Logically

Place fundamental validations (required fields, data types) before business rule validations (cross-field checks, policy enforcement). This is especially important when using "Stop on First Failure" mode.

Provide Clear Error Messages

Error messages should:

• Explain what's wrong
• Suggest how to fix it
• Be understandable by end users

❌ Bad:  "Validation failed"
✅ Good: "Due date must be at least 30 days after invoice date for international customers"