Conditional Validation YAML Reference Alpha

Complete reference for defining Event Rule and Custom Type variants using YAML configuration files.
Available Plans
  • free
  • starter
  • growth
  • enterprise

Conditional validation involves using two kinds of variants:

Both types share a common structure but are used in different contexts. This reference details the YAML schema and configuration options for both types.

Common variant structure

All variant definitions share the following structure:

PropertyTypeDescription
type
Required
StringMust be discriminator
discriminator
Required
StringFull path of the property that determines which variant case applies. Must match a required property defined in the parent object.
cases
Required
Array of case definitionsArray of variant cases defining different validation rules.
defaultdefault caseDefault validation rules when no case matches.

cases definition

Each case in the cases array has the following structure:

PropertyTypeDescription
id
Required
StringUnique identifier for the case within the variant.
display_name
Required
StringHuman-readable name for the case.
match
Required
ArrayArray of values that trigger this case. Values must match the discriminator property’s type.
description
Required
StringDescription explaining when this case applies.
propertiesArray of property referencesProperty requirements specific to this case.

default case

The optional default case has the following structure:

PropertyTypeDescription
properties
Required
Array of property referencesProperty requirements for when no case matches.

Property references

Property references in both cases and default case have this structure:

PropertyTypeDescription
$ref
Required
StringReference to a property defined in the parent object’s properties section.
requiredBooleanWhether the property is required. Defaults to false.

Supported types

This section lists the types supported for the discriminator and match properties.

Discriminator types

The following types are supported for the discriminator property:

TypeDescriptionExample valuesNotes
StringText-based discrimination"search", "US", "clothing"Case-sensitive matching
BooleanTrue/false discriminationtrue, falseSimple binary choices
NumberNumeric discrimination500, 1000, 2000Exact value matching
info

The discriminator property must be:

  • Defined in the parent object’s properties section
  • Marked as required
  • Have a type matching your match values (string, boolean, or number)

Match values

The match array in each case supports:

TypeFormatExample
StringArray of strings["US", "USA", "United States"]
BooleanArray of booleans[true] or [false]
NumberArray of numbers[500, 1000, 2000]
info

Note that for match values:

  • RudderStack matches the values exactly (no pattern or range matching)
  • String matches are case-sensitive
  • Each case can have multiple match values
  • All match values in a case must be of the same type as the discriminator

Variant schemas

info

For validation purposes, RudderStack uses JSON Schema rules where variants is defined as an array of objects, each requiring type: discriminator.

The examples in the below section show the actual YAML structure.

Variant structure examples

This section provides examples of how to define Event Rule and Custom Type variants using YAML configuration files.

Event Rule variant

variants:
  - type: discriminator
    discriminator: "page_type"
    cases:
      - id: search_page
        display_name: "Search Results Page"
        match: ["search", "search_results"]
        description: "When user is on search pages"
        properties:
          - $ref: "#/properties/search_term"
            required: true

Custom Type variant

variants:
  - type: discriminator
    discriminator: "country"
    cases:
      - id: us_address
        display_name: "US Address"
        match: ["US", "USA"]
        description: "US address format"
        properties:
          - $ref: "#/properties/state"
            required: true

See also



Questions? Contact us by email or on Slack