Start

Workflow execution entry point that defines input arguments and initializes workflow context.

The Start node is the entry point for all workflow execution. It defines input parameters, validates incoming data, and establishes the initial context for your workflow.

┌─────────────────────────────────────────────────────────┐
│                    WORKFLOW FLOW                        │
├─────────────────────────────────────────────────────────┤
│                                                         │
│    ┌─────────┐     ┌─────────┐     ┌─────────┐          │
│    │ TRIGGER │────▶│  START  │────▶│  LOGIC  │          │
│    │         │     │  NODE   │     │  NODES  │          │
│    └─────────┘     └─────────┘     └─────────┘          │
│         │               │               │               │
│    HTTP/Schedule/       |               |               |
|    GraphQL/SOAP    Input Validation  Processing         │
│         │               │               │               │
│         └───── Workflow Execution ──────┘               │
│                                                         │
└─────────────────────────────────────────────────────────┘

Configuration (Readonly)

Property	Value
Code	`start`
Node Type	START
Workflow Types	Workflow, Agentflow

Connections

Direction	Description
Outgoing	Connects to the first node in your workflow

Input Configuration

The Start node defines the data contract for your workflow. Configure inputs that external systems will provide when triggering your workflow.

Input Field Types

Type	Description	Example	Schema Support
Text	String values	`"user@example.com"`	❌ No
Integer	Whole numbers	`42`	❌ No
Boolean	True/false values	`true`	❌ No
Fractional	Decimal numbers	`3.14`	❌ No
Object	JSON objects	`{"name": "John", "age": 30}`	✅ Yes
Array	Lists of values	`["apple", "banana", "cherry"]`	❌ No

Field Configuration Options

Each input field supports various configuration options to control validation, structure, and behavior:

Option	Purpose	Example	Applies To
Required	Field must be provided	✓ Email address required	All types
Array	Accept multiple values	✓ List of email addresses	All types
Default Value	Fallback when field not provided	`"production"` for environment	All types
Description	Documentation for the field	"Customer email for notifications"	All types
Min Value	Minimum allowed value	`0` for age, `"2024-01-01"` for date	Integer, Fractional, Time
Max Value	Maximum allowed value	`150` for age, `"2024-12-31"` for date	Integer, Fractional, Time
JSON Schema	Object structure validation	Complex object validation	Object type only
Encrypted	Secure sensitive data	✓ API keys, passwords	All types

Common Configuration Combinations

Required Text Field:

{
  "customerEmail": {
    "type": "text",
    "required": true,
    "description": "Customer email address for order confirmation"
  }
}

Optional Array with Default:

{
  "tags": {
    "type": "text",
    "required": false,
    "isArray": true,
    "defaultValue": ["general"],
    "description": "Product categories"
  }
}

Numeric Range Validation:

{
  "quantity": {
    "type": "integer",
    "required": true,
    "minValue": "1",
    "maxValue": "999",
    "description": "Number of items to order"
  }
}

Encrypted Sensitive Data:

{
  "apiKey": {
    "type": "text",
    "required": true,
    "encrypted": true,
    "description": "Third-party API authentication key"
  }
}

Common Input Patterns

API Integration Pattern

{
  "apiEndpoint": {
    "type": "text",
    "required": true,
    "description": "Target API URL"
  },
  "apiKey": {
    "type": "text",
    "required": true,
    "description": "Authentication key"
  },
  "requestData": {
    "type": "object",
    "required": false,
    "default": {},
    "description": "Request payload",
    "jsonSchema": {
      "type": "object",
      "properties": {
        "userId": { "type": "string" },
        "action": { "type": "string", "enum": ["create", "update", "delete"] },
        "data": { "type": "object" }
      },
      "required": ["userId", "action"]
    }
  }
}

Data Processing Pattern

{
  "inputFile": {
    "type": "text",
    "required": true,
    "description": "File path or URL to process"
  },
  "outputFormat": {
    "type": "text",
    "required": false,
    "default": "json",
    "description": "Output format (json, csv, xml)"
  },
  "includeHeaders": {
    "type": "boolean",
    "required": false,
    "default": true,
    "description": "Include headers in output"
  }
}

Notification Pattern

{
  "recipients": {
    "type": "array",
    "required": true,
    "description": "Email addresses to notify"
  },
  "subject": {
    "type": "text",
    "required": true,
    "description": "Email subject line"
  },
  "emailConfig": {
    "type": "object",
    "required": false,
    "description": "Email configuration options",
    "jsonSchema": {
      "type": "object",
      "properties": {
        "priority": { "type": "string", "enum": ["low", "normal", "high"] },
        "template": { "type": "string" },
        "attachments": {
          "type": "array",
          "items": { "type": "string" }
        }
      },
      "additionalProperties": false
    }
  }
}

Input Validation

JSON Schema Validation

JSON schema validation is available for Object type inputs only. Each object input can have its own schema for validation:

{
  "userProfile": {
    "type": "object",
    "required": true,
    "jsonSchema": {
      "type": "object",
      "properties": {
        "email": {
          "type": "string",
          "pattern": "^[\\w-\\.]+@([\\w-]+\\.)+[\\w-]{2,4}$",
          "description": "Valid email address"
        },
        "age": {
          "type": "integer",
          "minimum": 0,
          "maximum": 150
        },
        "preferences": {
          "type": "object",
          "properties": {
            "newsletter": { "type": "boolean" },
            "language": { "type": "string", "enum": ["en", "fr", "es"] }
          }
        }
      },
      "required": ["email", "age"]
    }
  }
}

Validation Rules:

Only applies to inputs with type: "object"
Schema validates the object structure and field types
Validation occurs at workflow execution time
Invalid data returns a validation error with parameter name

Test variants allow you to configure multiple test data scenarios for Start nodes during workflow development and debugging. Each variant provides sample input data that simulates real workflow execution.

How Test Variants Work

Test variants are used during:

Individual Node Testing: When running specific nodes for testing in isolation
Workflow Debugging: When troubleshooting workflow behavior

Only one test variant can be active at a time per Start node. The active variant automatically provides its test data when the workflow runs in test mode.

Managing Test Variants

Create Test Variant: Add a new test data scenario with a unique code identifier
Set Active Variant: Mark one variant as active for testing
Configure Test Data: Provide JSON data matching your input schema
Run the start node: Run the start node. IMPORTANT: The execution result of the start node run is saved in the context so that it can be uses during development/testing of the other nodes in the workflow/agentflow.

Test Variant Structure

Each test variant contains:

Field	Description	Required
`code`	Unique identifier for the test variant	✅ Yes
`body`	JSON data containing input values	✅ Yes
`active`	Whether this variant is currently active	❌ No (default: false)

Example Test Variants

E-commerce Order Processing:

{
  "code": "standard-order",
  "active": true,
  "body": {
    "customerEmail": "test@example.com",
    "orderAmount": 99.99,
    "orderItems": [
      {"id": "item1", "quantity": 2},
      {"id": "item2", "quantity": 1}
    ],
    "priority": "normal"
  }
}

High-Priority Order:

{
  "code": "urgent-order",
  "active": false,
  "body": {
    "customerEmail": "vip@example.com",
    "orderAmount": 599.99,
    "orderItems": [
      {"id": "premium1", "quantity": 1}
    ],
    "priority": "urgent"
  }
}

Data Processing Workflow:

{
  "code": "sample-dataset",
  "active": true,
  "body": {
    "dataSource": "sales_data.csv",
    "filters": {
      "dateRange": "2024-01-01,2024-12-31",
      "region": "US"
    },
    "aggregations": ["sum", "avg", "count"],
    "outputFormat": "json"
  }
}

Best Practices

Use Descriptive Codes: Choose meaningful identifiers like "happy-path", "error-case", "edge-case"
Test Edge Cases: Create variants for boundary conditions, empty data, and error scenarios
Match Input Schema: Ensure test data structure matches your configured inputs exactly
Keep Data Realistic: Use representative data that mirrors production scenarios
Document Variants: Add comments in your test data to explain the test scenario

Data Type Conversion

Test variant data is automatically converted to match your configured input types:

{
  "textInput": "Hello World",     // String → Text
  "numberInput": 42,              // Number → Integer
  "decimalInput": 3.14,           // Number → Fractional  
  "flagInput": true,              // Boolean → Boolean
  "arrayInput": [1, 2, 3],        // Array → Integer Array
  "fileInput": "blob_id_xyz"      // String → File (blob ID)
}

Integration with Triggers

The Start node works with different trigger types:

Currently Available Triggers

Trigger Type	Input Source	Example Use Case
HTTP Trigger	Request body/query params	REST API endpoints
Schedule Trigger	Static configuration	Automated batch processing
GraphQL Trigger	GraphQL query/mutation variables	GraphQL API endpoints
SOAP Trigger	SOAP request envelope	Legacy system integration

Best Practices

Input Design

Keep it simple: Only require essential inputs
Provide defaults: Use sensible default values
Validate early: Catch invalid data at the entry point
Document clearly: Use descriptive field names and descriptions

Security Considerations

Input sanitization: Validate and sanitize all inputs
Size limits: Set reasonable limits for text and array inputs

Error Handling

Clear error messages: Provide actionable validation errors
Fail fast: Validate inputs before processing begins
Consistent format: Use standard error response format
Logging: Log validation failures for debugging

Troubleshooting

Common Issues

Problem	Cause	Solution
Missing required field	Input not provided	Check trigger configuration
Type mismatch	Wrong data type	Verify input type definitions
Validation failure	Invalid data format	Review validation rules
Default not applied	Required field with default	Make field optional

Debugging Tips

Use Test Variants: Test inputs before deployment
Check Logs: Review execution logs for validation errors
Validate Schema: Test JSON schema validation rules with Ojbect inputs
Trace Execution: Follow workflow execution from Start node

End Node

Define workflow outputs and responses

Axellero Studio

Development environment and visual builders

Start

End Node

Axellero Studio

On this page