Conditional Execution

Overview

Conditional Execution allows workflows to make intelligent decisions and follow different paths based on data, system state, or previous results. It enables dynamic workflows that adapt to varying conditions.

🔀 Purpose

Use Conditional Execution to:

• Run steps only when conditions are met

• Create branching workflows

• Handle different scenarios

• Implement smart decision logic

• Skip unnecessary steps

---

When to Use Conditional Execution

✅ Good Use Cases

Scenario	Reason
Environment-Based Logic	Different steps for dev/test/prod
Input Validation	Skip/modify based on data
Error Recovery	Take different path on failure
Feature Flags	Enable/disable features conditionally
Multi-Scenario Testing	Test different user types/states
Alternative Paths	Different decision branches
Status-Based Actions	Conditional notifications/alerts

❌ Anti-Patterns (Don't Do)

• ❌ Overly complex nested conditions

• ❌ Conditions that are hard to understand

• ❌ Missing the "else" path (what if false?)

• ❌ Conditions that change rarely (use config instead)

• ❌ Ignoring edge cases

---

Condition Types

Simple Comparison

Evaluate single values:

IF variable == "value" THEN
    [Execute Step A]
ELSE
    [Execute Step B]

Examples:

IF environment == "production" THEN
IF status_code == 200 THEN
IF count > 100 THEN
IF name != null THEN

Logical Operators

Combine multiple conditions:

IF (condition1 AND condition2) THEN
    [Execute if BOTH true]

IF (condition1 OR condition2) THEN
    [Execute if EITHER true]

IF NOT (condition) THEN
    [Execute if NOT true]

Complex Conditions

Chain multiple operators:

IF (status == "active" AND role == "admin") OR override == true THEN
    [Execute Step]
ELSE
    [Alternative Step]

Null/Empty Checks

Handle missing data:

IF variable IS NULL THEN
    [Handle missing value]

IF list IS EMPTY THEN
    [Handle empty list]

IF string HAS_LENGTH > 0 THEN
    [Process non-empty string]

---

Practical Examples

Example 1: Environment-Based Configuration

Workflow: Deploy Application

Step 1: Get Environment
   Output: env = "staging"

Step 2: IF env == "production" THEN
   Step 3a: [Load Production Config]
   Step 3b: [Run Security Checks]
   Step 3c: [Backup Database]
   Step 3d: [Deploy to Production]
   
ELSE IF env == "staging" THEN
   Step 3e: [Load Staging Config]
   Step 3f: [Deploy to Staging]
   Step 3g: [Run Smoke Tests]
   
ELSE
   Step 3h: [Load Development Config]
   Step 3i: [Deploy to Development]

Step 4: [Send Deployment Report]

Example 2: Error Recovery Path

Workflow: Resilient User Creation

Step 1: API - Create User
   Try: Create user
   Catch: error_message

Step 2: IF error_message IS NULL THEN
   [User created successfully]
   Step 3a: [Send Welcome Email]
   Step 3b: [Log Success]
   
ELSE IF error_message CONTAINS "duplicate email" THEN
   [Email already exists]
   Step 3c: [Check if user exists]
   Step 3d: [Send password reset]
   Step 3e: [Log Duplicate]
   
ELSE IF error_message CONTAINS "invalid email" THEN
   [Invalid input]
   Step 3f: [Return validation error]
   Step 3g: [Log Validation Error]
   
ELSE
   [Unknown error]
   Step 3h: [Send Error Alert]
   Step 3i: [Log Error]

Step 4: [Complete]

Example 3: Feature Flag Logic

Workflow: Test Premium Features

Step 1: API - Get User Features
   Output: features = ["basic", "premium", "analytics"]

Step 2: IF "premium" IN features THEN
   Step 3a: [Web - Navigate to Premium Dashboard]
   Step 3b: [Verify Premium Features Visible]
   Step 3c: [Test Premium Functionality]
   
ELSE
   Step 3d: [Web - Navigate to Basic Dashboard]
   Step 3e: [Verify Premium Features Hidden]
   Step 3f: [Verify Upsell Banner Shown]

Step 4: [Complete Feature Test]

Example 4: Multi-Tier User Testing

Workflow: User Role-Based Testing

Step 1: Get User Role
   Output: role = "manager"

Step 2: IF role == "admin" THEN
   [Run Admin Tests]
   - Full access tests
   - System configuration tests
   - User management tests
   
ELSE IF role == "manager" THEN
   [Run Manager Tests]
   - Team report access
   - Limited user management
   - Department configuration

ELSE IF role == "user" THEN
   [Run User Tests]
   - Personal profile access
   - Limited reporting
   - Self-service features

ELSE
   [Unknown role - log error]

Step 3: [Aggregate Results]
Step 4: [Send Role-Based Report]

Example 5: Complex Decision Tree

Workflow: Comprehensive System Check

Step 1: [Check API Health]
   Output: api_status

Step 2: [Check Database Health]
   Output: db_status

Step 3: IF (api_status == "healthy" AND db_status == "healthy") THEN
   [All systems go]
   Step 4a: [Run full test suite]
   
ELSE IF (api_status == "degraded" OR db_status == "degraded") THEN
   [Partial failure]
   Step 4b: [Run limited tests]
   Step 4c: [Alert operations]
   
ELSE
   [Critical failure]
   Step 4d: [Stop testing]
   Step 4e: [Emergency alert]
   Step 4f: [Page on-call engineer]

Step 5: [Send Status Report]

---

Building Conditions

Step 1: Identify Decision Point

Question: What varies in my workflow?
- Environment (dev/test/prod)?
- User type (admin/user)?
- Data state (exists/missing)?
- Previous result (success/failure)?

Step 2: Define Conditions

Clear conditions:
✅ "environment == production"
✅ "user.role == admin"
✅ "response.status == 200"
✅ "items.length > 0"

Unclear conditions:
❌ "something went wrong"
❌ "check if valid"
❌ "needs attention"

Step 3: Plan Paths

Main path: IF condition TRUE
   - What steps execute?
   - What's the goal?
   - How do we verify?

Alternative path: IF condition FALSE
   - What's the alternative?
   - Is it necessary?
   - Do we handle it?

Step 4: Test All Paths

Test coverage:
✅ Condition TRUE - main path works
✅ Condition FALSE - alternative path works
✅ Edge cases - null, empty, boundary values
✅ Error cases - exception handling

---

Best Practices

✅ Do

• Keep conditions simple - Easy to understand

• Name conditions clearly - Explain what you're checking

• Handle all paths - Include else/fallback

• Test all branches - Verify each path works

• Document logic - Use comments for complex conditions

• Avoid nesting deeply - Maximum 2-3 levels

• Validate inputs first - Check null before comparing

• Log decision points - Track which path executed

❌ Don't

• Create complex boolean logic - "if (a && (b || c) && !d)"

• Missing else path - What if condition is false?

• Change variables in conditions - Side effects cause bugs

• Ignore edge cases - Null, empty, unexpected values

• Nest conditions excessively - Hard to follow

• Use string comparisons - Use proper types

• Skip input validation - Validate before condition

• Forget to test failure paths - They happen in production

---

Condition Examples

Data Validation

Workflow: Validate Purchase Order

Step 1: Get Order Data
   Output: order

Step 2: IF order.total IS NULL THEN
   [Error: Missing total]
   
ELSE IF order.total < 0 THEN
   [Error: Negative amount]
   
ELSE IF order.items IS EMPTY THEN
   [Error: No items]
   
ELSE IF order.customer_id IS NULL THEN
   [Error: Invalid customer]
   
ELSE
   [Order is valid - continue processing]

Status-Based Routing

Workflow: Process Payment

Step 1: Process Payment
   Output: payment_status

Step 2: IF payment_status == "approved" THEN
   Step 3a: [Update Order Status]
   Step 3b: [Send Confirmation Email]
   Step 3c: [Fulfill Order]
   
ELSE IF payment_status == "pending" THEN
   Step 3d: [Wait for bank]
   Step 3e: [Retry after 1 hour]
   
ELSE IF payment_status == "declined" THEN
   Step 3f: [Send Decline Notification]
   Step 3g: [Suggest Alternative Payment]
   
ELSE
   Step 3h: [Alert Operations Team]

Threshold-Based Action

Workflow: Performance Monitoring

Step 1: Measure Response Time
   Output: response_time_ms

Step 2: IF response_time_ms < 100 THEN
   [Excellent - Log success]
   
ELSE IF response_time_ms < 500 THEN
   [Good - Log normal]
   
ELSE IF response_time_ms < 2000 THEN
   [Slow - Log warning]
   [Send team notification]
   
ELSE
   [Very Slow - Log critical]
   [Alert on-call engineer]

---

Real-World Scenarios

E-Commerce: Order Status Management

Workflow: Process Order

[Receive order]

IF order.payment_method == "credit_card" THEN
    [Process credit card payment]
ELSE IF order.payment_method == "paypal" THEN
    [Redirect to PayPal]
ELSE IF order.payment_method == "bank_transfer" THEN
    [Send bank details]
ELSE
    [Unknown payment method - error]

IF payment_successful THEN
    IF order.total > 1000 THEN
        [Send admin for approval]
    ELSE
        [Auto-approve]
    
    [Create fulfillment order]
    [Send confirmation email]
ELSE
    [Notify customer of failure]
    [Ask to retry or use different method]

API Testing: Multi-Status Handling

Workflow: Comprehensive API Testing

[Make API call]

IF response_status == 200 THEN
    [Parse successful response]
    IF response contains expected_field THEN
        [Validate data format]
        [Check data values]
    ELSE
        [Response missing fields]
        [Log error]
ELSE IF response_status == 404 THEN
    [Resource not found - expected]
    [Verify error message]
ELSE IF response_status == 500 THEN
    [Server error]
    [Retry with backoff]
ELSE
    [Unexpected status]
    [Alert team]

---

Troubleshooting

Issue: Condition never evaluates to true

Symptoms:

• Wrong path always executes

• Condition should be true but isn't

Causes:

• Variable value different than expected

• Comparison operator wrong

• Type mismatch (string vs number)

Solutions:

1. Log variable value before condition

2. Check expected vs actual

3. Verify data type

4. Add intermediate step to inspect

Issue: Nested conditions too complex

Symptoms:

• Hard to understand logic flow

• Difficult to test all paths

Solutions:

1. Flatten nested conditions

2. Use intermediate variables

3. Add comments explaining logic

4. Consider separate sub-workflows

Issue: Missing edge case

Symptoms:

• Workflow fails on unexpected input

• Null pointer exceptions

Solutions:

1. Add null checks first

2. Test with boundary values

3. Consider all possible states

4. Add default/fallback path

---

Condition Operators Reference

Comparison:
== (equal)
!= (not equal)
> (greater than)
< (less than)
>= (greater than or equal)
<= (less than or equal)

Logical:
AND - Both conditions must be true
OR - Either condition can be true
NOT - Inverse the condition

String:
CONTAINS - String includes substring
STARTS_WITH - String begins with
ENDS_WITH - String ends with
MATCHES - Regex pattern match

Collection:
IN - Value is in collection
NOT_IN - Value not in collection
IS_EMPTY - Collection has no items
HAS_LENGTH - Collection size check

Null/Type:
IS_NULL - Value is null
IS_NOT_NULL - Value is not null
IS_TYPE - Check value type

---

Related Topics

• Workflow Patterns - Common decision patterns

• Error Handling - Error-based conditions

• Custom Variables - Variables in conditions

• Execution Flow - How execution works

• Nodes and Steps - Building blocks

---

Summary

• Conditional Execution creates intelligent, adaptive workflows

• Use for decision points - Different paths for different scenarios

• Keep simple - Complex nested conditions are hard to test

• Handle all paths - Include both true and false outcomes

• Test thoroughly - Verify all branches work correctly

• Document decisions - Explain why each path exists

---

Next: Learn about Custom Variables for advanced data management.