Skip to main content

​
Understanding Workflow Engine Limitations

The Altostrat Workflow Engine provides powerful automation capabilities within defined operational boundaries. Understanding these limits and behaviors helps you design robust, efficient workflows that operate reliably at scale. Why limits exist:
  • Ensure system stability and performance
  • Prevent accidental resource misuse
  • Maintain fair resource allocation
  • Protect against infinite loops and runaway processes

​
Workflow Execution Limits

Execute workflows efficiently within these time and performance boundaries:

​
Execution Time Limits: Maximum Duration and Timeouts

Workflow runs have time boundaries to prevent runaway executions and ensure responsive automation:
  • Maximum workflow duration: 1 hour total execution time
  • Maximum node timeout: 5 minutes per individual action
  • Timeout behavior: Exceeding limits automatically terminates workflows with failed status
If you have a very long-running process, consider breaking it into multiple, smaller workflows linked together with the Trigger Workflow action.

​
Iterator Processing Limits: Batch Size and Nesting Controls

Iterator actions include safeguards to prevent system overload during batch processing:
  • Maximum batch size: 1,000 items per iterator execution
  • Maximum nesting depth: 5 levels of nested iterators
  • Failure behavior: Oversized arrays cause immediate step failure
  • Protection purpose: Prevents fork bomb scenarios and resource exhaustion

​
Delay Action Limits: Maximum Wait Times

Delay actions support short-term workflow pausing with these constraints:
  • Maximum delay duration: 15 minutes (900 seconds) per delay action
  • Intended use: Short-term waits and rate limiting
  • For longer delays: Use separate scheduled workflows for extended timing
This limit is based on the underlying queueing technology. For longer-term scheduled actions, it’s better to end the workflow and have a separate scheduled workflow to handle the follow-up task.

​
Data Retention: Log Storage and Archiving

Workflow execution data follows these retention policies:
  • Active retention: 90 days of runs and logs in primary database
  • Archive storage: Long-term archive for audit and compliance
  • UI access: Archived data not visible in main interface
  • Retrieval: Archived data available by request for audit purposes

​
Workflow Behavior Guide

Understand these specific behaviors for effective workflow design and debugging:

​
Variable Replacement: How Data Types Are Handled

Workflow variable replacement behaves differently based on context and data types:
For more advanced templating capabilities, see our Liquid Templating documentation.
  • Simple Replacement ({{ ... }} only): If a field contains only a variable reference, like {{ node_1.user }}, the system will replace it with the raw data type. If node_1.user is a JSON object, the field will become that JSON object.
  • Embedded Replacement (Hello {{...}}): If a variable is part of a larger string, like "User ID is {{ node_1.id }}", the system will convert the variable’s value to a string before inserting it. If the variable contains a JSON object or array, it will be converted into its JSON string representation.

​
Error Handling: Continue on Error Behavior

The “continue on error” setting fundamentally changes workflow execution flow:
  • The workflow does not stop.
  • The node’s output becomes an error object (e.g., {"error": true, "message": "API returned 503"}). This error object is added to the context.
  • The workflow proceeds only down the special error path from that node. The true, false, or default success paths are ignored.
  • If no error path is connected, that branch of the workflow simply terminates without failing the entire run.

​
Iterator Error Handling: All-or-Nothing Processing

Iterator actions use atomic error handling for consistent batch processing:
  • If any single item within the iteration fails its sub-workflow, the entire Iterator node is considered to have failed.
  • The parent workflow run will be immediately marked as failed, and processing of other items in the batch will be stopped. There is no partial success for an Iterator.

​
Infinite Loop Prevention: Circular Dependency Protection

The Workflow Engine includes multiple safeguards against infinite workflow loops:
  • On Save: When you save a workflow, the system checks all Trigger Workflow actions. If it detects a path that could lead back to the workflow being saved (e.g., A calls B, which calls C, which calls A), the save operation will be blocked with an error.
  • At Runtime: As an additional safeguard, the system tracks the “call stack” of a workflow run. If a workflow.triggered event is received for a workflow that is already in its own call stack, that trigger will be ignored to prevent a loop from starting.
⌘I