Execution Basics
Understanding the fundamental execution flow in Scrydon
When you run a workflow in Scrydon, the execution engine follows a systematic process to ensure blocks are executed in the correct order with proper data flow.
Execution Flow
The execution engine runs workflows in layers, processing blocks based on their dependencies:
Validation: Ensures the workflow has a starter block with no incoming connections and all blocks are properly connected.
Layer-based Execution: Identifies which blocks can execute next based on completed dependencies and executes them in parallel.
Path Updates: Router and Condition blocks update the active execution path, determining which blocks execute next.
Iteration Processing: Loop and Parallel blocks manage iterations and create virtual instances for concurrent execution.
Result Collection: Outputs from the final blocks are collected and returned as the workflow result.
Block Types and Execution
Different block types have different execution behaviors:
Orchestration blocks control the flow of execution through your workflow.
- Starter BlockInitiates workflow execution and provides initial input values. Every workflow must have exactly one starter block.
- Router BlockDirects execution along specific paths based on dynamic decisions. Uses an AI model to select one of multiple possible paths.
- Condition BlockExecutes different paths based on conditional logic. Evaluates JavaScript expressions to determine which path to follow.
- Loop BlockExecutes blocks repeatedly for a fixed number of iterations or over a collection. Manages iteration state and provides access to current item.
- Parallel BlockExecutes blocks concurrently across multiple instances. Distributes work based on count or collection for faster processing.
Processing blocks transform data and generate new outputs.
- Agent BlockInteracts with AI models to generate content. Executes prompts against various LLM providers.
- Function BlockExecutes custom JavaScript/TypeScript code. Runs in a secure sandbox environment with access to connected block outputs.
- Evaluator BlockAssesses outputs against defined criteria. Uses AI to evaluate content based on custom metrics.
- Workflow BlockExecute nested workflows as a single block. Allows modular workflow design by embedding one workflow inside another.
Integration blocks connect with external systems.
- API BlockMakes HTTP requests to external services. Configurable with headers, body, and authentication.
- Knowledge Base BlockSearch and interact with knowledge bases. Performs semantic search, retrieves documents, and manages knowledge data.
- Response BlockFormat and return responses from workflows. Configure response data, status codes, and headers.
- Tool BlocksSpecialized blocks for specific services (Gmail, Slack, GitHub, etc.). Each has its own execution logic for the specific service.
Execution Methods
Scrydon offers multiple ways to trigger workflow execution:
Manual Execution
Run workflows on-demand through the Scrydon interface by clicking the "Run" button. This is perfect for:
- Testing during development
- One-off tasks
- Workflows that need human supervision
Scheduled Execution
Configure workflows to run automatically on a specified schedule:
- Set up recurring executions using cron expressions
- Define start times and frequency
- Configure timezone settings
- Set minimum and maximum execution intervals
Viewing deployments
Each environment's deployed version, promotion history, and rollback options are visible in the workflow editor's Deployments panel. Open it with the Deploy button in the editor toolbar (it reads Versions once everything is deployed). The panel shows:
- A vertical pipeline stepper with one row per environment: deployed version, when it was promoted, by whom, and a promote button (primary only on the first pending hop).
- An Agent endpoints section — one section for the whole workflow, not per environment — listing published A2A agents as rows (
A2A Agent · <visibility> · serves <environment>). - A collapsed History & rollback section with a count, for reverting to an earlier deployment version.
Webhooks
Configure workflows to execute in response to external events:
- Set up webhook triggers from third-party services
- Process incoming webhook data as workflow input
- Configure webhook security settings
- Support for specialized webhooks (GitHub, Stripe, etc.)
The execution method you choose depends on your workflow's purpose. Manual execution is great for development, while scheduled execution, API endpoints, and webhooks are better for production use cases.
Execution Context
Each workflow execution maintains a context that tracks:
- Block States: Outputs and execution status of each block
- Execution Path: Active blocks based on routing decisions
- Loop/Parallel State: Current iterations and distribution items
- Environment Variables: Configuration values available during execution
- Execution Logs: Detailed records of each block's execution
Real-Time Monitoring
Monitor your workflow execution in real-time:
- Active Block Highlighting: Currently executing blocks pulse with animation
- Live Logs: Execution logs appear instantly in the logs panel
- Block States: Visual indicators show running, success, error, pending, or skipped states with a reason
- Performance Metrics: Execution time for each block
These monitoring features help you understand workflow behavior and quickly identify any issues.