Built into field settings, these validations apply to individual fields:

• Required Fields: Must have a value before saving
• Data Type Validation: Ensures correct format (numbers, dates, emails)
• Min/Max Values: Numeric and date range constraints
• Text Length: Minimum and maximum character limits
• Pattern Matching: Regular expressions for specific formats
• Unique Values: Prevent duplicate entries

Component-level rules that control form behavior:

• Display Rules: Show/hide fields based on conditions
• Submit Rules: Control when forms can be submitted
• Validation Rules: Cross-field validation logic
• Conditional Requirements: Fields required only under certain conditions

Custom validation through automation:

• Table Rules: Enforce constraints at database level
• Record Rules: Implement form-specific business logic
• Equation Fields: Calculate and validate derived values
• Connection Constraints: Enforce relationship rules

Purpose: Ensure critical data is always provided.

Configuration:

• Edit field settings
• Toggle "Required" option
• Set custom error message (optional)

Example Use Cases:

• Customer name and email required
• Order must have at least one line item
• Approval decision must be recorded

Email fields automatically validate format:

• Must contain @ symbol
• Valid domain format
• No spaces or invalid characters

Custom Email Validation:

• Require specific domains (e.g., only @company.com)
• Use validation rules to check format
• Prevent disposable email addresses

Number field constraints:

• Minimum Value: e.g., Price must be at least $0
• Maximum Value: e.g., Discount cannot exceed 100%
• Decimal Places: Control precision (e.g., currency: 2 decimals)
• Positive Only: Prevent negative numbers

Example: Age field

• Minimum: 18
• Maximum: 120
• Error Message: "Age must be between 18 and 120"

Date field constraints:

• Minimum Date: e.g., Start date cannot be in the past
• Maximum Date: e.g., End date cannot be more than 1 year out
• Date Range: Must fall within specific period

Example: Event date validation

• Minimum: Today (prevent scheduling past events)
• Maximum: 2 years from now
• Error Message: "Event date must be between today and 2 years from now"

Text field constraints:

• Minimum Length: e.g., Password at least 8 characters
• Maximum Length: e.g., Tweet limited to 280 characters
• Exact Length: e.g., ZIP code must be exactly 5 digits

Prevent duplicate values:

• Email addresses must be unique
• Username cannot be duplicated
• Order numbers must be unique
• SKU codes cannot repeat

Configuration:

• Edit field settings
• Enable "Unique Values" option
• Set error message: "This {field_name} already exists"

Scenario: Show "Other Description" field only when user selects "Other" in a dropdown.

Configuration:

• Field: Other Description
• Display Rule: Show when Category equals "Other"
• Result: Field is hidden until "Other" is selected

Scenario: Show "Manager Approval" section only to managers.

Configuration:

• Fields: Approval Comments, Approval Date
• Display Rule: Show when Logged-in User Role equals "Manager"
• Result: Only managers see and can fill these fields

Scenario: Show shipping address fields only if "Ship to different address" is checked.

Configuration:

• Fields: Shipping Street, Shipping City, Shipping State, Shipping Zip
• Display Rule: Show when "Different Shipping Address" checkbox is checked
• Result: Form is cleaner, showing only relevant fields

Scenario: End date must be after start date.

Configuration:

• Validation Rule: End Date is greater than Start Date
• Error Message: "End date must be after start date"
• Result: Form cannot be submitted if dates are invalid

Scenario: Total expenses cannot exceed approved budget.

Configuration:

• Validation Rule: Total Expenses is less than or equal to Approved Budget
• Error Message: "Total expenses ($[total]) exceed approved budget ($[budget])"
• Result: Prevents over-budget submissions

Scenario: Order quantity cannot exceed available stock.

Configuration:

• Validation Rule: Quantity is less than or equal to Product.Stock_Available
• Error Message: "Only {stock} units available"
• Result: Prevents orders that cannot be fulfilled

Scenario: High-value orders require manager approval before submission.

Configuration:

• Submit Rule: Allow submit when Total is less than $5,000 OR Manager Approval equals "Yes"
• Error Message: "Orders over $5,000 require manager approval"
• Result: Form cannot be submitted until approval is obtained

Scenario: Multi-section form requires all sections completed.

Configuration:

• Submit Rule: All required fields in each section are filled
• Error Message: "Please complete all required sections"
• Result: Ensures comprehensive data collection

Scenario: Calculate age from birthdate and ensure user is at least 18.

Implementation:

• Equation Field: Age = DATEDIFF(Birthdate, Today, "years")
• Validation Rule: Age is greater than or equal to 18
• Error Message: "You must be at least 18 years old"

Scenario: Ensure discount percentage doesn't result in negative total.

Implementation:

• Equation Field: Discounted_Total = Subtotal * (1 - Discount_Percent / 100)
• Validation Rule: Discounted_Total is greater than 0
• Error Message: "Discount percentage is too high"

Scenario: Prevent registration when event is full.

Implementation:

• Event Table:
  • Max_Capacity field (number)
  • Current_Registrations equation field (counts connected registrations)
• Registration Form:
  • Validation Rule: Event.Current_Registrations is less than Event.Max_Capacity
  • Error Message: "Sorry, this event is full"
• Alternative: Use record rule to set status to "Waitlisted" when full

Scenario: Prevent orders that exceed customer's credit limit.

Implementation:

• Customer Table:
  • Credit_Limit field
  • Current_Balance equation field (sum of unpaid invoices)
  • Available_Credit equation field (Credit_Limit - Current_Balance)
• Order Form:
  • Validation Rule: Order_Total is less than or equal to Customer.Available_Credit
  • Error Message: "This order exceeds available credit of ${available_credit}"

Scenario: Orders must progress through statuses in order: Draft → Submitted → Approved → Shipped → Delivered.

Implementation:

• Table Rule 1: Prevent skipping from Draft directly to Shipped
  • Trigger: Record Edited
  • Condition: Status changed to "Shipped" AND Previous_Status equals "Draft"
  • Action: Set Status back to previous value, show error
• Alternative: Use action links with specific status transitions instead of allowing direct editing

Scenario: Once an order is marked "Shipped", it cannot be changed back to "Processing".

Implementation:

• Form Validation: Disable status field when Status equals "Shipped" or "Delivered"
• Or Table Rule:
  • Trigger: Record Edited
  • Condition: Previous_Status is in ["Shipped", "Delivered"] AND New_Status is in ["Draft", "Processing"]
  • Action: Revert status, log error

Scenario: Users cannot register for the same event twice.

Implementation:

• Registration Form Validation:
  • Check if a registration already exists for this user and event
  • Use equation field or validation rule
  • Error Message: "You are already registered for this event"
• Alternative: Make combination of User + Event unique

• Be Specific: Explain exactly what's wrong
• Be Helpful: Tell users how to fix it
• Be Friendly: Avoid technical jargon
• Be Clear: Use simple, direct language

Requirement: Appointments can only be scheduled during business hours (9 AM - 5 PM, Monday - Friday).

Implementation:

• Validation Rules:
  • Appointment Time is greater than or equal to 9:00 AM
  • Appointment Time is less than 5:00 PM
  • Appointment Day is not Saturday or Sunday
• Error Message: "Appointments can only be scheduled Monday-Friday, 9 AM - 5 PM"

Requirement: Cannot close a project if it has open tasks.

Implementation:

• Project Table:
  • Open_Tasks equation field (counts tasks where Status ≠ "Completed")
• Validation Rule:
  • When setting Status to "Closed", Open_Tasks must equal 0
  • Error Message: "Cannot close project. {open_tasks} tasks are still open."

Requirement: If user selects "Other" for payment method, payment details field becomes required.

Implementation:

• Display Rule: Show Payment Details when Payment Method equals "Other"
• Validation Rule: When Payment Method equals "Other", Payment Details is not empty
• Error Message: "Please provide payment details for 'Other' payment method"

• Are all required fields marked as required?
• Do email fields validate format?
• Are numeric fields constrained to valid ranges?
• Are dates within acceptable ranges?
• Are unique values enforced where needed?

• Are workflow status transitions enforced?
• Are capacity limits checked?
• Are budget/credit limits validated?
• Are dependencies between records enforced?
• Are duplicates prevented?

• Are error messages clear and helpful?
• Do forms show only relevant fields?
• Is validation immediate (where appropriate)?
• Are users guided to correct errors?
• Is feedback provided on successful submission?

• Are sensitive operations validated?
• Are user permissions checked?
• Is input sanitized against injection?
• Are file uploads validated?

• Is the validation rule enabled?
• Are conditions correct?
• Is field name spelled correctly?
• Does the validation apply to the right form/component?

• Are conditions too restrictive?
• Are you comparing the right data types?
• Are null values handled correctly?
• Test with edge cases

• Are multiple rules conflicting?
• Is there circular logic?
• Do display rules hide required fields?
• Review rule execution order

• Catch errors as soon as possible
• Provide immediate feedback
• Don't wait until form submission

• Clear, specific error messages
• Highlight problem fields
• Show how to fix errors
• Don't use technical jargon

• Field-level validation for basic constraints
• Form-level validation for cross-field logic
• Server-side validation (table rules) for critical business rules

• Test with valid data
• Test with invalid data
• Test edge cases and boundary conditions
• Test with different user roles

• Explain why validation exists
• Document business logic
• Maintain validation rule inventory

• Use field-level validation for basic constraints
• Implement form-level validation for cross-field logic
• Enforce business rules with table rules and equations
• Provide clear, helpful error messages
• Show/hide fields conditionally for better UX
• Prevent duplicates and enforce uniqueness
• Validate capacity limits and dependencies
• Test thoroughly with various scenarios
• Layer validation for comprehensive coverage