Overview

Sim's execution engine brings your workflows to life by processing blocks in the correct order, managing data flow, and handling errors gracefully, so you can understand exactly how workflows are executed in Sim.

Every workflow execution follows a deterministic path based on your block connections and logic, ensuring predictable and reliable results.

Documentation Overview

Key Concepts

Topological Execution

Blocks execute in dependency order, similar to how a spreadsheet recalculates cells. The execution engine automatically determines which blocks can run based on completed dependencies.

Path Tracking

The engine actively tracks execution paths through your workflow. Router and Condition blocks dynamically update these paths, ensuring only relevant blocks execute.

Layer-Based Processing

Instead of executing blocks one-by-one, the engine identifies layers of blocks that can run in parallel, optimizing performance for complex workflows.

Execution Context

Each workflow maintains a rich context during execution containing:

  • Block outputs and states
  • Active execution paths
  • Loop and parallel iteration tracking
  • Environment variables
  • Routing decisions

Deployment Snapshots

API, Chat, Schedule, and Webhook executions run against the workflow’s active deployment snapshot. Manual runs from the editor execute the current draft canvas state, letting you test changes before deploying. Publish a new deployment whenever you change the canvas so every trigger uses the updated version.

Deployment versions table

The Deploy modal keeps a full version history—inspect any snapshot, compare it against your draft, and promote or roll back with one click when you need to restore a prior release.

Programmatic Execution

Execute workflows from your applications using our official SDKs:

# TypeScript/JavaScript
npm install simstudio-ts-sdk

# Python
pip install simstudio-sdk
// TypeScript Example
import { SimStudioClient } from 'simstudio-ts-sdk';

const client = new SimStudioClient({ 
  apiKey: 'your-api-key' 
});

const result = await client.executeWorkflow('workflow-id', {
  input: { message: 'Hello' }
});

Best Practices

Design for Reliability

  • Handle errors gracefully with appropriate fallback paths
  • Use environment variables for sensitive data
  • Add logging to Function blocks for debugging

Optimize Performance

  • Minimize external API calls where possible
  • Use parallel execution for independent operations
  • Cache results with Memory blocks when appropriate

Monitor Executions

  • Review logs regularly to understand performance patterns
  • Track costs for AI model usage
  • Use workflow snapshots to debug issues

What's Next?

Start with Execution Basics to understand how workflows run, then explore Logging to monitor your executions and Cost Calculation to optimize your spending.

Common Questions

Synchronous executions (API, chat) have a default timeout of 5 minutes on the Free plan and 50 minutes on Pro, Team, and Enterprise plans. Asynchronous executions (schedules, webhooks) allow up to 90 minutes across all plans. These limits are configurable by the platform administrator.
The engine identifies layers of blocks with no dependencies on each other and runs them concurrently. Within loops and parallel blocks, the engine supports up to 20 parallel branches by default and up to 1,000 loop iterations. Nested subflows (loops inside parallels, or vice versa) are supported up to 10 levels deep.
Yes. The engine supports cancellation through an abort signal mechanism. When you cancel an execution, the engine checks for cancellation between block executions (at roughly 500ms intervals when using Redis-backed cancellation). Any in-progress blocks complete, and the execution returns with a cancelled status.
A deployment snapshot is a frozen copy of your workflow at the time you click Deploy. Trigger-based executions (API, chat, schedule, webhook) run against the active snapshot, not your draft canvas. Manual runs from the editor execute the current draft canvas state, so you can test changes before deploying. You can view, compare, and roll back snapshots from the Deploy modal.
Costs are tracked per block based on the AI model used. Each block log records input tokens, output tokens, and the computed cost using the model's pricing. The total workflow cost is the sum of all block-level costs for that execution. You can review costs in the execution logs.
When a block throws an error, the engine captures the error message in the block log, finalizes any incomplete logs with timing data, and halts the execution with a failure status. If the failing block has an error output handle connected to another block, that error path is followed instead of halting entirely.
Yes. The run-from-block feature lets you select a specific block and re-execute from that point. The engine computes which upstream blocks need to be re-run (the dirty set) and preserves cached outputs from blocks that have not changed, so only the affected portion of the workflow re-executes.

On this page