Variables

A variable is a value you set yourself and reuse across a workflow. Sim has two kinds. Workflow variables hold data during a run, like a counter or a config object, and you reference them with <variable.name>. Environment variables hold secrets and configuration, like API keys, and you reference them with {{KEY}}.

One syntax, named sources

Everything in angle brackets is the same mechanism: <name.path> reads a value by name at run time. The first segment says where the value comes from. variable is literal — every workflow variable is read through it. A connection tag starts with the block's own name instead, and inside a container, loop and parallel are reserved for its context. {{KEY}} is the one different syntax, for environment variables.

The table is in resolution order: when an angle-bracket reference could match more than one source — say a block named variable — loop and parallel context win, then workflow variables, then block outputs. ({{KEY}} can't collide; it's a different syntax.) If nothing matches, the raw reference is left in place unsubstituted, which usually breaks the block that reads it — so give variables and blocks distinct names.

Type < in any block text field to open the picker and browse everything you can reference.

Workflow variables

Workflow variables are a global store any block can read or update during a run. Open the panel with ⋯ → Variables in the top-right of the editor. Each variable has a name, a type, and a value.

Reference one anywhere a field accepts input. For an object or array variable, use dot notation to reach a nested value, like <variable.config.timeout>. Name matching ignores case and spaces, so a variable named My Counter resolves from <variable.mycounter> — but a name can't contain a period: everything after the first dot is read as a path into the value, so <variable.config.timeout> always means the timeout field of config, never a variable named config.timeout. Consistent names like camelCase are the clearest.

Types

"Hello, World!"

42

true

{ "name": "John", "age": 30 }

[1, 2, 3, "four", "five"]

Scope

Workflow variables are global: every block in the workflow can read and modify them. Use the Variables block to update a value mid-run.

Each run starts fresh from the values defined in the panel. A change made during a run is visible to later blocks in that same run, but it never alters the saved initial value for future runs.

Environment variables

Environment variables let you keep sensitive values like API keys and tokens out of your saved workflow configuration. Create them under Settings → Secrets by adding a key-value pair.

Reference them with double curly braces in any block field, including Agent system prompts and Function block code. Most fields resolve the reference before the block runs. Function and Custom Tool code preserve {{KEY}} until their shared compiler runs at the execution boundary, where the value is bound separately from the source. This keeps its exact string contents out of saved and executed source code. When a saved secret is successfully resolved through {{KEY}}, exact occurrences of that value are masked in the live block-log display and stored execution trace without changing the runtime value. Exact secret values are also projected back to placeholders before content is sent to a model. See Execution log protection for the exact scope and limitations.

{{API_KEY}}

Personal vs. workspace

When a workspace and a personal variable share a key, the workspace value wins.

Use an environment variable for a raw API key or config value. When a service needs OAuth or managed token refresh (Slack, GitHub, Google), use a credential instead, selected from a dropdown in the block's config.

Next