Conditional Task

Overview

Conditional Tasks enable workflow branching based on defined rules and conditions. Each rule evaluates output parameters from previous tasks, allowing for dynamic workflow execution paths. This feature lets you create intelligent workflows that respond to data variations and task outcomes.

Visual Example

Conditional Task Example

Configuration Structure

{
    "type": "CONDITIONAL_TASK",
    "block": {
        "name": "Route Customer Request",
        "type": "CONDITIONAL_TASK",
        "rules": [
            {
                "conditions": [
                    {
                        "task": "Analyze Request",
                        "parameter": "sentiment_score",
                        "parameter_type": "FLOAT",
                        "operator": "LESS_THAN",
                        "value": "0.3"
                    },
                    {
                        "task": "Analyze Request",
                        "parameter": "urgency",
                        "parameter_type": "STRING",
                        "operator": "EQUAL",
                        "value": "high"
                    }
                ],
                "then_block": "Escalate Request"
            },
            {
                "conditions": [
                    {
                        "task": "Analyze Request",
                        "parameter": "category",
                        "parameter_type": "STRING",
                        "operator": "EQUAL",
                        "value": "refund"
                    }
                ],
                "then_block": "Process Refund"
            }
        ],
        "dependencies": ["Analyze Request"],
        "error_policy": "RAISE"
    }
}

Required Fields

FieldTypeDescriptionRequired
namestringTask identifierYes
rulesarrayArray of condition rulesYes
dependenciesarrayTask dependenciesNo
error_policystringError handling strategyNo

Rules Configuration

Each conditional task must have one or more rules. Rules are evaluated in the order they appear in the configuration.
{
    "rules": [
        {
            "conditions": [...],
            "then_block": "Task ID"
        }
    ]
}

Rule Structure

Each rule contains:
  • conditions: Array of conditions that must ALL be satisfied (AND operation)
  • then_block: The task to execute if all conditions are met (defaults to “END” if not specified)

Condition Configuration

{
    "conditions": [
        {
            "task": "Previous Task Name",
            "parameter": "output_parameter_name",
            "parameter_type": "STRING",
            "operator": "EQUAL",
            "value": "expected_value"
        }
    ]
}

Condition Fields

FieldTypeDescriptionRequired
taskstringSource task (must be a dependency)Yes
parameterstringOutput parameter from the source taskYes
parameter_typeenumData type of the parameterYes
operatorenumComparison operatorYes
valueanyValue to compare againstYes*
* Not required for operators like IS_NULL, IS_NOT_NULL, IS_EMPTY, IS_NOT_EMPTY

Parameter Types

The following parameter types are supported:
TypeDescriptionExample Values
STRINGText values”approval”, “high”, “rejected”
INTEGERWhole numbers1, 42, -10
FLOATDecimal numbers0.5, 3.14, -2.5
BOOLEANTrue/false valuestrue, false
DATETIMEDate and time values”2024-03-15 14:30:00”
ARRAYLists of values[1, 2, 3], [“red”, “green”]
ENUMPredefined set of values”APPROVED”, “REJECTED”

Available Operators

The available operators depend on the data type of the selected parameter:

String Operators

  • EQUAL: Exact match
  • NOT_EQUAL: Not an exact match
  • CONTAINS: String contains value
  • STARTS_WITH: String starts with value
  • ENDS_WITH: String ends with value
  • IS_NULL: Value is null
  • IS_NOT_NULL: Value is not null

Numeric Operators (INTEGER, FLOAT)

  • EQUAL: Equal to
  • NOT_EQUAL: Not equal to
  • GREATER_THAN: Greater than
  • LESS_THAN: Less than
  • GREATER_THAN_OR_EQUAL: Greater than or equal to
  • LESS_THAN_OR_EQUAL: Less than or equal to
  • IS_NULL: Value is null
  • IS_NOT_NULL: Value is not null

Boolean Operators

  • EQUAL: Equal to (true/false)
  • NOT_EQUAL: Not equal to (true/false)
  • IS_NULL: Value is null
  • IS_NOT_NULL: Value is not null

DateTime Operators

  • EQUAL: Equal to
  • NOT_EQUAL: Not equal to
  • GREATER_THAN: Later than
  • LESS_THAN: Earlier than
  • GREATER_THAN_OR_EQUAL: Later than or equal to
  • LESS_THAN_OR_EQUAL: Earlier than or equal to
  • IS_NULL: Value is null
  • IS_NOT_NULL: Value is not null

Array Operators

  • IS_EMPTY: Array has no elements
  • IS_NOT_EMPTY: Array has at least one element

Enum Operators

  • EQUAL: Exact match
  • NOT_EQUAL: Not an exact match

Then Block Configuration

The then_block field specifies which task to execute if all conditions in the rule are satisfied.
{
    "then_block": "Next Task Name"
}
  • If no then_block is specified, or if it is set to “END”, the workflow will terminate
  • Only tasks that have been connected to the conditional task in the workflow editor will appear in the dropdown

Common Use Cases

1. Content Routing

{
    "name": "Route Content",
    "rules": [
        {
            "conditions": [
                {
                    "task": "Analyze Content",
                    "parameter": "toxicity_score",
                    "parameter_type": "FLOAT",
                    "operator": "GREATER_THAN",
                    "value": "0.7"
                }
            ],
            "then_block": "Human Review"
        },
        {
            "conditions": [
                {
                    "task": "Analyze Content",
                    "parameter": "toxicity_score",
                    "parameter_type": "FLOAT",
                    "operator": "LESS_THAN",
                    "value": "0.2"
                }
            ],
            "then_block": "Publish Content"
        }
    ],
    "dependencies": ["Analyze Content"],
    "error_policy": "RAISE"
}

2. Customer Support Triage

{
    "name": "Triage Support Request",
    "rules": [
        {
            "conditions": [
                {
                    "task": "Classify Request",
                    "parameter": "priority",
                    "parameter_type": "STRING",
                    "operator": "EQUAL",
                    "value": "high"
                }
            ],
            "then_block": "Urgent Support"
        },
        {
            "conditions": [
                {
                    "task": "Classify Request",
                    "parameter": "category",
                    "parameter_type": "STRING",
                    "operator": "EQUAL",
                    "value": "billing"
                }
            ],
            "then_block": "Billing Department"
        }
    ],
    "dependencies": ["Classify Request"],
    "error_policy": "RAISE"
}

3. Data Validation

{
    "name": "Validate Data",
    "rules": [
        {
            "conditions": [
                {
                    "task": "Extract Data",
                    "parameter": "records",
                    "parameter_type": "ARRAY",
                    "operator": "IS_EMPTY"
                }
            ],
            "then_block": "Handle Empty Dataset"
        },
        {
            "conditions": [
                {
                    "task": "Extract Data",
                    "parameter": "validation_score",
                    "parameter_type": "FLOAT",
                    "operator": "LESS_THAN",
                    "value": "0.8"
                }
            ],
            "then_block": "Clean Data"
        }
    ],
    "dependencies": ["Extract Data"],
    "error_policy": "RAISE"
}

Task Flow

Flow Execution Logic

  • Rules are evaluated in sequential order (top to bottom)
  • The first rule with all conditions satisfied determines the execution path
  • If multiple rules could match, only the first matching rule is executed
  • If no rules match, the workflow proceeds to END unless a default path is configured

Error Policies

The error_policy field defines how errors are handled during rule evaluation:
PolicyDescription
RAISEStop workflow execution and raise an error (default)
RETRYRetry the condition evaluation after a delay
SKIPSkip the failing condition and continue evaluation
{
    "error_policy": "RETRY",
    "retry_count": 3,
    "retry_delay": 5
}

Best Practices

1. Rule Organization

Do:
  • Order rules from most specific to most general
  • Group related conditions
  • Use descriptive names for tasks and parameters
  • Test rule evaluation with sample data
Don’t:
  • Create overlapping rules without clear precedence
  • Use complex nested conditions when simpler rules would work
  • Add unnecessary conditions
  • Create circular dependencies

2. Condition Design

Do:
  • Use appropriate operators for each data type
  • Validate input values
  • Consider edge cases
  • Keep conditions simple and clear
Don’t:
  • Mix data types in comparisons
  • Use hardcoded values that may change
  • Create impossible conditions
  • Overcomplicate conditions

3. Workflow Integration

Do:
  • Ensure all referenced tasks exist in the workflow
  • Verify parameter names and types
  • Use clear task names for easy reference
  • Document rule logic for other users
Don’t:
  • Reference tasks outside the workflow
  • Use parameters that may not exist
  • Create dead-end paths
  • Assume parameters will always have values

Common Issues and Solutions

IssueSolution
Rules Never MatchCheck condition values and operators
Wrong Branch SelectedReview rule order and specificity
Missing ParametersVerify task dependencies and output structure
Type ErrorsEnsure parameter values match expected data types
Workflow Dead EndsConnect all possible branches to appropriate tasks
Parameter ChangedUpdate conditions if output parameter names change
No Next Node OptionsConnect edges to destination nodes in the workflow